The stealthy toolkit embeds a backdoor in HAProxy and targets automotive and media organizations in South Korea for long-term surveillance.
The post North Korean Hackers Deploy New Linux Espionage Toolkit appeared first on SecurityWeek.
https://www.securityweek.com/north-korean-hackers-deploy-new-linux-espionage-toolkit/
OpenAI agents made 15,000–18,000 autonomous edits to a German wiki over three months, evading moderation and echoing tactics seen in the Hugging Face breach.
The post OpenAI Agents Hijack Another Victim Website appeared first on SecurityWeek.
https://www.securityweek.com/openai-agents-hijack-another-victim-website/
The StyleSmuggler zero-day allows attackers to execute code and deploy a stealthy backdoor on Adobe Commerce and Magento stores.
The post Adobe Commerce Zero-Day Exploited to Backdoor Online Stores appeared first on SecurityWeek.
https://www.securityweek.com/adobe-commerce-zero-day-exploited-to-backdoor-online-stores/
The attacks rely on backdoored ScreenConnect instances to transfer and execute payloads to newly connected clients.
The post Modified ScreenConnect Clients Used in Worm-Like Campaign appeared first on SecurityWeek.
https://www.securityweek.com/modified-screenconnect-clients-used-in-worm-like-campaign/
Il 3 settembre 2026 Broadcom ha pubblicato il bollettino VMSA-2026-0007. Corregge due vulnerabilità di VM escape, cioè di fuga dalla macchina virtuale, in VMware Workstation e Fusion: una di gravità critica e una di gravità alta. Lo stesso giorno il CSIRT Italia ha diffuso l’alert AL03/260903/CSIRT-ITA, con impatto sistemico stimato “Alto” (65,76). Per la maggior parte delle organizzazioni è un ordinario aggiornamento. Per chi lavora in un laboratorio di analisi malware o in una postazione di informatica forense il problema è diverso. Workstation e Fusion sono lo strumento con cui, ogni giorno, si esegue codice ostile di proposito, confidando che resti confinato. Le due falle mettono in discussione proprio quel confine.
Le due vulnerabilità colpiscono componenti diversi dell’hypervisor, ma condividono il modello di minaccia: un attaccante con privilegi amministrativi dentro la macchina virtuale ottiene esecuzione di codice sul sistema ospitante.
CVE-2026-59346 è un integer overflow nel controller di rete virtuale VMXNET3. Broadcom la classifica come critica, con punteggio CVSSv3 massimo di 9,3. Secondo il bollettino, un attaccante con privilegi amministrativi locali su una macchina virtuale dotata di adattatore VMXNET3 può sfruttarla per eseguire codice sull’host. L’hanno segnalata, in modo indipendente, un ricercatore di secsys lab e due ricercatori che collaborano con la Zero Day Initiative (indicata nel bollettino come “TrendAI Zero Day Initiative”).
CVE-2026-59347 è uno stack buffer overflow in HGFS (Host-Guest File System), il meccanismo delle cartelle condivise tra guest e host. Il punteggio è 8,1 e la gravità è “importante”. Nella scala VMware il termine corrisponde alla fascia “alta” di FIRST, tra 7,0 e 8,9. Lo sfruttamento consente di eseguire codice con i privilegi del processo VMX della macchina virtuale sull’host. L’hanno segnalata due ricercatori del Tencent Xuanwu Lab.
Le versioni interessate sono la 25H2 e la 26H1, sia di Workstation (su qualsiasi sistema operativo host) sia di Fusion (su macOS). La correzione è nella versione 26H1u1, rilasciata il 3 settembre per entrambi i prodotti. Le note di rilascio indicano la build 25688693 per Workstation Pro e la build 25689522 per Fusion Pro.
Broadcom indica che non esistono misure alternative all’aggiornamento. Il dato va letto insieme alla politica di risposta VMware: per le vulnerabilità di gravità critica il produttore si impegna a cercare una modifica di configurazione che chiuda i vettori di attacco noti. Per CVE-2026-59346, che rientra in quella fascia, la ricerca non ha dato esito.
Un dettaglio tecnico merita attenzione. Il vettore CVSS di CVE-2026-59346 indica complessità di attacco bassa (AC:L); quello di CVE-2026-59347 indica complessità alta (AC:H). In termini pratici, la falla su VMXNET3 è quella più facile da trasformare in un codice di attacco funzionante. Entrambi i vettori riportano un cambio di ambito (S:C), coerente con un impatto che supera il perimetro del componente vulnerabile.
Sullo sfruttamento, il bollettino descrive entrambe le vulnerabilità come segnalate privatamente e non contiene note su attacchi osservati. Il silenzio ha un peso: la politica VMware prevede che i bollettini riportino in nota la conferma di sfruttamento, quando esiste. L’alert del CSIRT Italia, al 3 settembre, non registra né codice di attacco pubblico né sfruttamento. Alla data di pubblicazione di questo articolo, la scheda di CVE-2026-59346 su cve.org risulta ancora nello stato “reserved”, cioè priva di dettagli tecnici. È una fotografia del momento, non una garanzia: i precedenti insegnano che la situazione può cambiare in fretta.
La virtualizzazione desktop nasce per far convivere sistemi diversi sulla stessa macchina, non per contenere un avversario. L’isolamento tra guest e host è un effetto utile dell’architettura. Poggia però su decine di migliaia di righe di codice che emulano dispositivi: schede di rete, controller di archiviazione, schede grafiche, canali di comunicazione con l’host. Ogni dispositivo emulato è una superficie che il guest può sollecitare con dati arbitrari.
Le due falle di settembre colpiscono esattamente questo strato. VMXNET3 è un dispositivo di rete paravirtualizzato: il guest gli invia descrittori di pacchetti che il processo VMX sull’host deve interpretare. HGFS è un protocollo di condivisione file: il guest formula richieste che l’host esegue sul proprio file system. In entrambi i casi il codice che elabora i dati provenienti dal guest gira sull’host, con i privilegi del processo VMX.
Non è un caso isolato. La sequenza degli ultimi diciotto mesi lo mostra.
Nel marzo 2025 il bollettino VMSA-2025-0004 aveva corretto tre vulnerabilità in ESXi, Workstation e Fusion. La prima era un heap overflow nel componente VMCI (CVE-2025-22224, anch’esso a 9,3); la seconda una scrittura arbitraria in ESXi (CVE-2025-22225); la terza una lettura fuori limite proprio in HGFS (CVE-2025-22226). Le aveva segnalate il Microsoft Threat Intelligence Center. Broadcom dichiarò di avere informazioni su uno sfruttamento già avvenuto per almeno le prime due. CISA inserì le tre CVE nel catalogo KEV lo stesso 4 marzo, con scadenza di rimedio al 25 marzo. Per CVE-2025-22225 il catalogo registra oggi anche l’uso in campagne ransomware. Il modello di attacco era lo stesso di oggi: privilegi amministrativi nel guest, esecuzione di codice come processo VMX sull’host.
Il 29 luglio 2026 il bollettino VMSA-2026-0006 ha corretto, tra le altre, CVE-2026-47876. È una scrittura fuori limite nell’adattatore VMXNET3 di ESX, anch’essa a 9,3 e senza misure alternative. Il vettore di attacco è lo stesso: privilegi amministrativi in un guest con VMXNET3, esecuzione di codice sull’host. La falla era emersa alla competizione Pwn2Own tramite un ricercatore di STARLabs SG. Lo stesso bollettino correggeva in Workstation e Fusion 25H2 una lettura fuori limite (CVE-2026-41703), con impatto limitato alla divulgazione di informazioni. Cinque settimane dopo, lo stesso adattatore virtuale torna al centro di un bollettino, questa volta sui prodotti desktop.
La conclusione operativa è semplice da enunciare e scomoda da applicare. Un hypervisor di tipo 2, che gira come applicazione sopra un sistema operativo generico, offre un isolamento probabilistico, non un confine di sicurezza garantito. Va trattato come tale.
Un laboratorio di analisi dinamica è, per definizione, l’ambiente in cui il modello di minaccia del bollettino si realizza per scelta. Il campione viene eseguito nel guest, spesso con privilegi amministrativi, perché è così che si osserva il comportamento completo di un malware. Il requisito “attaccante con privilegi amministrativi nella macchina virtuale” non va conquistato: è la configurazione di partenza.
Un elemento di contesto: Workstation Pro e Fusion Pro sono gratuiti anche per uso commerciale ed educativo, senza chiave di licenza, come ricordano le note di rilascio. È ragionevole attendersi che questo abbia abbassato la soglia di adozione anche per piccole strutture, studi di consulenza e corsi universitari, dove la gestione degli aggiornamenti è meno strutturata.
Alcune configurazioni ricorrenti in questi ambienti amplificano il rischio:
Va detto che il malware con capacità di VM escape resta raro: la maggior parte dei campioni si limita a rilevare la virtualizzazione e a cambiare comportamento. Ma la valutazione va fatta sul campione peggiore, non su quello medio. Un laboratorio che analizza attività di gruppi strutturati, o campioni ricevuti durante un incidente in corso, deve considerare l’ipotesi che l’avversario conosca queste falle prima che siano pubbliche.
Il risvolto forense è il più delicato, perché sposta il problema dal piano tecnico a quello processuale, dove contano integrità della prova e catena di custodia.
Contaminazione dell’ambiente di analisi. Molti consulenti tecnici usano Workstation o Fusion per esaminare immagini forensi. Si monta la copia del disco in una macchina virtuale, oppure si avvia direttamente l’immagine per ricostruire l’operatività del sistema. Se il sistema esaminato contiene codice malevolo capace di VM escape, la postazione forense diventa un sistema compromesso. Da quel momento ogni strumento in esecuzione sull’host, compresi quelli di acquisizione e di calcolo degli hash, opera su una piattaforma di cui non si può più garantire l’integrità.
Ripetibilità dell’accertamento. L’articolo 360 del codice di procedura penale disciplina gli accertamenti tecnici non ripetibili, con garanzie di partecipazione per la difesa. Un accertamento condotto su una piattaforma compromessa può essere contestato come non ripetibile nelle medesime condizioni, perché lo stato dell’ambiente di analisi non è documentato né ricostruibile. Questa è un’interpretazione di chi scrive, non un orientamento giurisprudenziale consolidato; è però un argomento che una difesa attenta può sollevare.
Conservazione dei dati originali. La legge 18 marzo 2008, n. 48, che ha ratificato la Convenzione di Budapest, ha modificato con il Capo III il codice di procedura penale (D.P.R. 22 settembre 1988, n. 447). Tre articoli, sulle ispezioni (244, comma 2), sulle perquisizioni disposte dall’autorità giudiziaria (247, comma 1-bis) e su quelle di iniziativa della polizia giudiziaria (352, comma 1-bis), usano la stessa formula: le operazioni sui sistemi informatici vanno svolte “adottando misure tecniche dirette ad assicurare la conservazione dei dati originali e ad impedirne l’alterazione”. L’articolo 354, comma 2, sugli accertamenti urgenti, va oltre: la polizia giudiziaria deve impedire l’alterazione e l’accesso ai dati e provvedere, ove possibile, alla loro duplicazione immediata “mediante una procedura che assicuri la conformità della copia all’originale e la sua immodificabilità”. La stessa esigenza torna nell’articolo 260, comma 2, per la copia dei dati sequestrati. Il legislatore, in altre parole, chiede integrità e immodificabilità della copia: proprietà che presuppongono una piattaforma di acquisizione non compromessa.
Lo standard ISO/IEC 27037:2012 va nella stessa direzione per le fasi di identificazione, raccolta, acquisizione e conservazione della prova digitale. Va precisato che la norma esclude espressamente la fase di analisi e non impone strumenti specifici: la credibilità dell’accertamento poggia sulla metodologia applicata e sulla qualificazione di chi la esegue. Tre definizioni della norma sono utili qui. La ripetibilità (punto 3.17) è la proprietà di un processo di dare gli stessi risultati nello stesso ambiente di prova: stesso computer, stesso disco, stessa modalità operativa. La riproducibilità (3.18) è la proprietà di dare gli stessi risultati in un ambiente di prova diverso. La spoliazione (3.19) è ogni modifica alla prova, provocata o anche solo consentita, che ne riduce il valore probatorio. Un consulente può sostenere che un hypervisor con una vulnerabilità nota e non corretta incrina tutte e tre: l’ambiente di prova non è più documentabile come stabile, e una fuga dal guest è una modifica consentita per omissione. Anche questa è una lettura interpretativa, non una posizione espressa dalla norma.
Documentazione nel verbale. La contromisura documentale non ha costi e va adottata subito. Nel verbale di acquisizione o nella relazione tecnica vanno riportati: prodotto, versione e build dell’hypervisor (per esempio “VMware Workstation Pro 26H1u1, build 25688693”); data dell’ultimo aggiornamento; configurazione della macchina virtuale, con adattatore di rete, cartelle condivise e strumenti di integrazione guest attivi. Se l’accertamento è avvenuto su una versione vulnerabile prima della pubblicazione del bollettino, è preferibile darne atto spontaneamente. L’alternativa è che lo scopra la controparte.
L’aggiornamento alla 26H1u1 è il primo passo, non l’ultimo. Le misure che seguono riducono la superficie esposta anche alle vulnerabilità future di questa classe:
Chi affida all’esterno l’analisi di campioni o la perizia su dispositivi ha titolo per porre domande precise. Non serve competenza tecnica per formularle, e le risposte dicono molto sulla maturità del fornitore:
Un fornitore che risponde con precisione a queste domande ha già affrontato il problema.
Le due vulnerabilità corrette da VMSA-2026-0007 verranno chiuse dall’aggiornamento nella maggior parte degli ambienti. La lezione per i laboratori di analisi e per le postazioni forensi è invece durevole. Tre bollettini in diciotto mesi, con lo stesso modello di attacco, mostrano che l’isolamento di una macchina virtuale è una proprietà del software, con i difetti del software. Chi esegue codice ostile per mestiere deve progettare l’ambiente sapendo che, prima o poi, quel confine verrà attraversato.
https://www.ictsecuritymagazine.com/notizie/vm-escape-vmware-workstation/
Due vulnerabilità concatenate di PaperCut NG/MF sono state usate per rubare credenziali a scuole e atenei in Europa e negli Stati Uniti. Il caso mostra perché un server di stampa integrato con la directory va trattato come sistema critico, anche ai fini NIS2.
Un server di gestione delle stampe compare raramente negli inventari delle risorse critiche. Eppure, tra fine agosto e i primi di settembre 2026, attaccanti non identificati lo hanno usato per raccogliere credenziali di scuole e università in Europa e negli Stati Uniti. Lo documenta l’analisi dell’Adversary Research Team di Arctic Wolf, datata 4 settembre e ripresa dalla stampa specializzata il giorno seguente. La catena di sfruttamento parte da due vulnerabilità di PaperCut NG/MF. In pochi passaggi arriva agli hive del registro di Windows e ai file di configurazione che custodiscono le credenziali verso Active Directory e LDAP.
Le vulnerabilità erano già note. La novità del rapporto è il quadro completo: chi viene colpito, con quali strumenti e che cosa cercano gli attaccanti una volta dentro.
Il rapporto, firmato dagli analisti Jens Pose e Ross Phillips, documenta lo sfruttamento di server PaperCut vulnerabili a CVE-2026-81578 e CVE-2026-82078. Le attività osservate comprendono esecuzione di comandi, ricognizione e tentativi di creare account privilegiati. Arctic Wolf ha precisato a The Hacker News che le vittime appartengono al settore dell’istruzione in senso ampio: dalle scuole primarie e secondarie (il segmento statunitense K-12) alle grandi università, negli Stati Uniti e in Europa. Nessuna istituzione è stata nominata e il rapporto non propone alcuna attribuzione.
La cronologia mostra quanto rapidamente si è aperta la finestra di esposizione. Le date, indicate di seguito, sono tratte dall’avviso di sicurezza di PaperCut, dall’avviso CISA e dal rapporto Arctic Wolf; dove la fonte è un’azienda di sicurezza:
Sul piano tecnico, PaperCut classifica CVE-2026-81578 come difetto di controllo degli accessi nell’interfaccia web di amministrazione (CWE-306, CVSS 4.0 pari a 8.8). In determinate condizioni, richieste remote non autenticate dirette a funzioni amministrative attivano azioni prima che la verifica degli accessi sia completata. L’effetto è la modifica di alcune configurazioni di sistema. CVE-2026-82078 (CWE-470, CVSS 4.0 pari a 9.4) riguarda invece il caricamento dinamico non sicuro di classi Java nelle utilità di connessione al database. L’applicazione istanzia i driver in base a nomi configurabili, senza confrontarli con una lista di driver approvati. Concatenate, le due falle permettono di eseguire bytecode Java arbitrario nel contesto del processo del server PaperCut, senza credenziali e senza interazione dell’utente. John Hammond di Huntress ha sintetizzato così a Cybersecurity Dive: all’attaccante basta l’indirizzo IP o il nome host del bersaglio.
Il produttore considera potenzialmente interessate tutte le versioni di PaperCut NG e MF. Le patch di emergenza coprono le versioni 24, 25 e 26; per le precedenti l’indicazione è aggiornare alla versione corrente.
Guardato dalla funzione, PaperCut conta pagine, applica quote e rilascia le stampe in modo sicuro. Guardato dalla posizione in rete, il quadro cambia. L’Application Server sincronizza utenti e gruppi da Active Directory, LDAP, Microsoft Entra ID o Google Workspace, come documenta il manuale del prodotto. Conserva quindi credenziali di collegamento (bind) verso la directory, spesso associate ad account di servizio con privilegi più ampi del necessario. Deve essere raggiungibile da tutte le postazioni e da tutte le multifunzione dell’organizzazione; questo lo colloca spesso in segmenti di rete poco filtrati. In molte realtà educative è inoltre pubblicato su internet per consentire la stampa via web e il rilascio da dispositivi mobili.
Si aggiunge un fattore organizzativo. Il sistema di stampa è spesso gestito da un fornitore esterno o rientra nel contratto di noleggio delle multifunzione. Gli aggiornamenti seguono i tempi del fornitore, non quelli del rischio. Il risultato è una risorsa con accesso alla directory, esposta verso l’esterno, con un ciclo di patch lento e spesso senza un responsabile interno.
Non è la prima volta che PaperCut finisce al centro di una campagna simile. Nella primavera 2023 le vulnerabilità CVE-2023-27350 e CVE-2023-27351 furono sfruttate, secondo le ricostruzioni dell’epoca, per distribuire i ransomware LockBit e Clop; anche allora il CSIRT Italia diffuse un alert sullo sfruttamento attivo. Lo schema si ripete: un componente considerato accessorio diventa la porta d’ingresso verso il dominio.
La parte più utile del rapporto di Arctic Wolf descrive che cosa fanno gli attaccanti dopo aver ottenuto l’esecuzione di codice. La sequenza è coerente su più vittime.
cmd.exe con pc-app.exe, il processo del server PaperCut, come processo padre. Le forme registrate sono cmd.exe /d /s /c "ver || uname -a" e cmd /c "whoami & ver & tasklist"; la prima è costruita per funzionare sia su Windows sia su Linux.Administrator17./custom/pcp_<10 caratteri>.txt o /custom/web/pcp_<10 caratteri>.txt nelle directory di PaperCut. Vengono poi recuperati con richieste GET dall’indirizzo 45.142.193[.]132, con User-Agent python-requests/2.32.5.certutil.exe vengono scaricati dallo stesso indirizzo, sulla porta 8000, gli eseguibili lsa_collect.exe, lsa_collect_small.exe e save_hives.exe. In sandbox, Arctic Wolf ha osservato lsa_collect.exe estrarre chiavi di registro per ricostruire il BootKey di sistema, che dà accesso al database SAM e quindi agli hash delle password locali.194.180.48[.]134, con sessioni stabilite verso lo stesso host.findstr /s /i /n /c:"password" /c:"secret" /c:"bind" /c:"ldap" /c:"token" sui file *.config di PaperCut.L’ultimo passaggio è quello che, a nostro avviso, collega il server di stampa al dominio: le stringhe cercate sono quelle che identificano le credenziali di bind verso LDAP e Active Directory e i token di integrazione.
Gli indicatori pubblicati dal produttore sono concreti. Nel server.log vanno cercate stringhe come jdbc:derby:memory:pwn;create=true, ERROR DatabaseUtils - Database error looking up cardID: VALUES CAST, ERROR No suitable driver found for jdbc:no:x e VALUES CAST(X'cafebabe, dove cafebabe è la firma esadecimale di un file .class Java. Sono sospetti anche log mancanti, troncati o cancellati. Nel file system vanno cercati file .class in server\lib e file .cmd e .out in server\data\content, tutti con nomi casuali di cinque caratteri; il produttore avverte che gli attaccanti li rimuovono man mano che l’attività procede. Sui dispositivi, la regola di rilevamento più efficace è la più semplice: pc-app.exe che genera cmd.exe, powershell.exe o altri interpreti, con revisione della riga di comando e del traffico di rete associato. Sul fronte delle identità, occorre esaminare gli eventi di gestione degli account alla ricerca di Administrator17 e di qualsiasi utenza privilegiata creata a ridosso di attività anomale sul server di stampa.
Il produttore ha inoltre documentato una sequenza post compromissione diversa da quella di Arctic Wolf, osservata dove la protezione dei dispositivi non ha bloccato l’esecuzione. Dopo whoami & ver e tasklist, l’attaccante enumera i controller di dominio con nltest /dclist: ed elenca sessioni e cartelle utente con quser e dir c:\users. Poi scarica con PowerShell un eseguibile (ace.exe) da un servizio di condivisione file e lo installa in modalità silenziosa. Il risultato è un servizio Windows chiamato “Remote Access Service”, che esegue l’agente SimpleHelp come LocalSystem con avvio automatico; circa mezz’ora dopo viene scaricato AnyDesk. L’intera sequenza dura meno di trenta minuti dal primo comando. Il comando nltest /dclist: conferma l’interesse per i controller di dominio prima ancora del consolidamento dell’accesso remoto. PaperCut raccomanda di cercare quel servizio e installazioni impreviste di AnyDesk.
Un punto va sottolineato: un server aggiornato oggi può essere stato compromesso ieri. La patch chiude la porta, non espelle chi è già entrato; la stessa BOD 26-04 di CISA fissa aspettative su quando le agenzie devono verificare una compromissione precedente alla patch. In caso di sospetta compromissione, il produttore raccomanda di mettere in sicurezza i backup, ricostruire da zero l’Application Server e ripristinare un backup precedente all’attività sospetta. A questo va aggiunta, per prudenza, la rotazione di tutte le credenziali che il server conosceva: account di servizio della directory, credenziali del database esterno, chiavi API e token di integrazione.
Secondo quanto riportato da BleepingComputer, Shadowserver rileva oltre 800 server PaperCut NG/MF raggiungibili da internet; il dato, che non abbiamo verificato direttamente sulla piattaforma Shadowserver, non distingue tra sistemi già protetti, honeypot e istanze vulnerabili. Per un ateneo o un istituto scolastico la verifica è semplice. Basta interrogare i servizi di scansione passiva (Shodan, Censys, la stessa Shadowserver per gli enti abilitati) sulle porte predefinite dell’Application Server, 9191 e 9192. Vanno aggiunte le porte 80 e 443 quando l’interfaccia è pubblicata dietro un reverse proxy. Il risultato va confrontato con l’inventario degli indirizzi pubblici. Se l’interfaccia di amministrazione risponde da fuori, l’istanza va trattata come potenzialmente toccata.
Le indicazioni del produttore sono lineari: limitare subito l’accesso web a indirizzi fidati, con regole firewall, liste di controllo o restrizioni sul reverse proxy; applicare la Emergency Patch Release 3 anche se si è già installata la prima o la seconda; aggiornare anche Site Server e server di stampa secondari, non solo l’Application Server principale. Mobility Print, Print Deploy, i client utente e i prodotti cloud Hive e Pocket non sono interessati. Chi usa la ricerca dei numeri di tessera su un database esterno deve riattivare esplicitamente la funzione nel file security.properties, perché dopo la patch è disabilitata per impostazione predefinita. Nelle scuole senza personale tecnico interno, il primo passo è chiedere al fornitore delle multifunzione se il server PaperCut è raggiungibile da internet e quale versione è installata: due domande a cui si risponde in pochi minuti.
Il CSIRT Italia ha pubblicato il 31 agosto l’alert AL04/260831/CSIRT-ITA sullo sfruttamento attivo delle due CVE, con impatto sistemico “critico” (78,71). L’alert indica come vulnerabili le versioni precedenti alla 24.1.9, alla 25.0.12 e alla 26.0.4 Emergency Patch Release 2; è uscito prima della Release 3 dell’1 settembre, che resta la versione di riferimento. PaperCut è un prodotto seguito con continuità dal CSIRT: a giugno 2026 un alert aveva segnalato una vulnerabilità di gravità alta nel client Print Deploy per Windows (CVE-2026-6645), e nel 2023 lo sfruttamento delle CVE-2023-27350 e 27351. Per il lettore italiano, però, la questione non è solo di gestione delle patch.
Il D.Lgs. 4 settembre 2024, n. 138, che recepisce la direttiva NIS2, colloca il mondo della ricerca nel perimetro per due vie. L’Allegato II, tra gli altri settori critici, elenca al punto 7 le organizzazioni di ricerca. L’Allegato III, che individua le pubbliche amministrazioni soggette al decreto ai sensi dell’articolo 3, comma 6, comprende tra gli altri soggetti pubblici gli enti e le istituzioni di ricerca. Le università non rientrano automaticamente in nessuna delle due categorie. La direttiva, all’articolo 6, punto 41, definisce organizzazione di ricerca il soggetto che svolge in via principale ricerca applicata o sviluppo sperimentale a fini commerciali, ed esclude espressamente gli istituti di istruzione. L’articolo 2, paragrafo 5, lettera b), lascia però agli Stati membri la facoltà di includere gli istituti di istruzione, in particolare quando svolgono attività di ricerca critiche.
Il legislatore italiano ha esercitato questa facoltà. L’Allegato IV del decreto elenca al punto 2 gli “istituti di istruzione che svolgono attività di ricerca”. Accanto figurano il trasporto pubblico locale, i soggetti di interesse culturale e le società in house o a controllo pubblico. Per questi soggetti il decreto si applica indipendentemente dalle dimensioni, ma solo dopo l’individuazione da parte dell’Autorità nazionale competente NIS su proposta delle Autorità di settore (articolo 3, commi 8 e 13). Un ateneo non è nel perimetro per il solo fatto di esistere: lo è quando ACN glielo notifica. L’articolo 3, comma 9, lettera f), prevede inoltre che vi possa essere attratto chi è critico come elemento sistemico della catena di approvvigionamento, anche digitale, di un soggetto essenziale o importante. È una clausola che riguarda da vicino i fornitori che gestiscono servizi come la stampa per conto di atenei ed enti.
Per i soggetti nel perimetro, gli obblighi di notifica sono operativi dal gennaio 2026, come ricorda ACN nel rapporto sul primo semestre. L’articolo 25 del decreto fissa la sequenza. Pre-notifica al CSIRT Italia senza ingiustificato ritardo, e comunque entro 24 ore dalla conoscenza dell’incidente significativo, indicando ove possibile se derivi da atti malevoli. Notifica entro 72 ore, con una valutazione iniziale di gravità e impatto e, se disponibili, gli indicatori di compromissione. Relazione finale entro un mese, con descrizione dell’incidente, causa originaria e misure di attenuazione. Lo stesso articolo definisce significativo l’incidente che ha causato, o è in grado di causare, una grave perturbazione operativa o perdite finanziarie, oppure ripercussioni considerevoli su terzi. A nostro giudizio un furto di credenziali della directory da un server di stampa può rientrare in questa definizione: l’impatto potenziale riguarda l’intera identità digitale dell’ente, e la norma chiede di valutare l’idoneità a causare il danno, non solo il danno già prodotto.
Le misure di gestione del rischio dell’articolo 24, comma 2, del decreto (che riprende l’articolo 21 della direttiva) contengono tre elementi che questa vicenda mette alla prova. La lettera i) affianca le politiche di controllo dell’accesso alla “gestione dei beni e degli assetti”: un inventario che non comprende il server PaperCut, o lo classifica come periferica, non permette di valutare il rischio. La lettera d) impone la sicurezza della catena di approvvigionamento, compresi i rapporti con i diretti fornitori e fornitori di servizi, e il comma 3 chiede di considerare le vulnerabilità specifiche di ciascun fornitore: se il sistema è gestito da terzi, il contratto deve prevedere tempi per le patch di emergenza, accesso ai log e obblighi di comunicazione in caso di incidente. Le stesse politiche di controllo dell’accesso implicano che l’account di servizio usato da PaperCut verso la directory abbia privilegi di sola lettura sugli attributi necessari, e non sia un account amministrativo riutilizzato.
Le scuole del primo e del secondo ciclo, che di norma non svolgono attività di ricerca, restano in gran parte fuori dal perimetro NIS2. Non restano fuori dal problema. PaperCut è diffuso negli istituti scolastici perché gestisce quote di stampa per studenti e docenti, e gli istituti operano con risorse di sicurezza minime, spesso senza un referente tecnico interno. In questi contesti la responsabilità di fatto ricade sul fornitore delle multifunzione e sull’ufficio tecnico della scuola, che raramente ha visibilità sulla configurazione del server. È qui che le indicazioni operative contano più delle norme.
Per chi gestisce direttamente il sistema:
pc-app.exe come processo padre di interpreti di comandi e ai file pcp_*.txt.Per chi si affida a un fornitore esterno, le domande da porre per iscritto sono cinque:
Le risposte a queste domande dicono più di qualsiasi certificazione. E ricordano che il percorso più breve verso il dominio raramente passa dai sistemi che tutti considerano critici; passa da quelli che nessuno pensa di guardare.
https://www.ictsecuritymagazine.com/notizie/vulnerabilita-papercut-attacchi-scuole-universita/
Dal 4 settembre 2026 un attacco senza correzione ufficiale colpisce i negozi Magento Open Source aggiornati. Le mitigazioni disponibili sono di terze parti. Per gli e-commerce italiani si aprono due questioni giuridiche: la notifica al Garante e la responsabilità dell’agenzia.
Dal 4 settembre 2026 gli e-commerce basati su Magento Open Source e Adobe Commerce sono esposti a un attacco attivo. Il produttore non ha ancora pubblicato una correzione. La vulnerabilità, chiamata StyleSmuggler dalla società olandese Sansec che l’ha scoperta, permette a un attaccante non autenticato di eseguire codice sul server del negozio e di installare una backdoor persistente.
Al 6 settembre Adobe non ha pubblicato avvisi, identificativi CVE, patch o soluzioni temporanee. L’indice dei bollettini di sicurezza di Adobe Commerce si ferma all’aggiornamento dell’11 agosto (APSB26-92). Quel bollettino correggeva sette CVE, tra cui un’escalation di privilegi non autenticata con punteggio CVSS 9.1 (CVE-2026-71362), e dichiarava che Adobe non era a conoscenza di exploit in circolazione. Secondo Sansec, la prossima release di sicurezza è prevista per l’8 settembre, ma non è noto se coprirà questo difetto.
Questo articolo non ripercorre la cronaca. Si concentra sul vuoto tra la scoperta e la patch. Cosa può fare oggi un esercente italiano che tratta dati di pagamento? Quali limiti hanno le mitigazioni non ufficiali? Quali obblighi giuridici scattano quando la compromissione è probabile ma non accertata?
La cronologia dell’avviso di Sansec fissa la prima esecuzione confermata dell’exploit alle 22:20 UTC del 4 settembre. Alle 22:40 Sansec ha individuato la campagna; alle 23:10 il suo scanner eComscan ha segnalato l’impianto su negozi non collegati tra loro. Nelle ore successive Sansec ha riprodotto l’intera catena su installazioni pulite di Magento Open Source 2.4.7, 2.4.8 e 2.4.9. Le regole di blocco del suo prodotto Shield sono entrate in funzione il 5 settembre alle 07:15 UTC. L’avviso è uscito lo stesso giorno, prima del completamento dell’analisi, perché i negozi venivano compromessi in quel momento.
L’attacco abusa del sistema di template di Magento, in particolare delle proprietà styles, per aggirare le protezioni esistenti. Si svolge in due fasi:
var/report/. Disrex Group, società olandese di hosting e sviluppo Magento, ha gestito la risposta a due negozi compromessi. In entrambi i casi ha osservato l’avvelenamento di var/log/system.log: l’attaccante invia un codice negozio non valido e Magento lo registra così com’è. Secondo Disrex questa fase non è filtrabile a livello di server web, perché è indistinguibile da un’integrazione malfunzionante.La ricostruzione del meccanismo, pubblicata da Disrex in un documento dedicato, è un’interpretazione indipendente. Secondo questa lettura, una direttiva {{block}} nel testo iniettato conduce, attraverso una catena di classi native di Magento, fino a codice pensato per il solo compilatore di dependency injection da riga di comando. Quel codice termina con un include su un percorso scelto dall’attaccante: il log avvelenato un istante prima. Disrex ha corretto una prima versione che identificava un punto di ingresso sbagliato. Sansec non ha confermato la ricostruzione né pubblicato la catena completa; Disrex non ha diffuso la richiesta assemblata. Per le stesse ragioni questo articolo non riporta dettagli riproducibili.
Una volta ottenuta l’esecuzione, un dropper PHP prova in ordine sei funzioni di avvio processo (shell_exec, exec, system, passthru, proc_open, popen) e usa la prima disponibile. Poi scarica e avvia l’impianto: un binario Rust statico e privo di simboli di circa 1,9 MB, per x86-64 e arm64. Il file viene installato in ~/.local/share/.gvfsd/gvfsd-user, nella home dell’utente del sito e non nella cartella web. Il processo si maschera con il nome [kworker/u:8:0], tipico di un thread del kernel Linux. Una voce cron lo riavvia ogni cinque minuti; è scritta direttamente nel file di spool, così il registro di sistema non mostra alcuna sostituzione del crontab.
Il dato che più dovrebbe preoccupare i responsabili IT è il profilo della prima vittima documentata da Sansec. Girava su Magento 2.4.6-p15, con le patch di luglio e agosto 2026 applicate e security:patch-status pulito. È il livello più alto che Adobe distribuisce per la linea 2.4.6, quello che il bollettino di agosto etichetta 2.4.6-2026-aug. Secondo la cronologia delle versioni, il supporto ordinario di quella linea è terminato l’11 agosto 2026, con supporto esteso fino ad agosto 2027. Essere aggiornati non ha protetto.
Il secondo caso documentato è l’opposto. Il negozio 2.4.7-p2 gestito da Disrex girava su un livello del 13 agosto 2024, otto livelli indietro rispetto al 2.4.7-p10 del 12 maggio 2026. L’esito è stato lo stesso. Come scrive Disrex, il livello di patch non dice nulla sull’esposizione.
Il perimetro noto al 6 settembre è il seguente:
La cronologia di Disrex aggiunge un elemento che va oltre il caso specifico. Il suo primo negozio è stato colpito alle 23:10 UTC del 4 settembre, cinquanta minuti dopo la prima esecuzione confermata a livello mondiale e otto ore prima che esistesse qualsiasi regola di blocco. Nessun livello di patch e nessuna firma avrebbero coperto quella finestra. È l’argomento più forte a favore delle misure di sistema indipendenti dalla vulnerabilità, descritte più avanti.
Non esistono statistiche ufficiali sulla diffusione di Magento in Italia. Chi voglia stimare l’esposizione nazionale può usare servizi di rilevamento tecnologico come BuiltWith o W3Techs con filtro geografico. Questi strumenti contano i domini, non le installazioni, e non distinguono in modo affidabile Open Source da Adobe Commerce. La domanda pratica è un’altra: il mio sito espone l’endpoint /graphql e quale vetrina lo usa? Vale anche ricordare che StyleSmuggler non è un caso isolato. A giugno una falla nel modulo di terze parti Mirasvit Full Page Cache Warmer (CVE-2026-45247), segnalata in questa rassegna, apriva anch’essa a esecuzione di codice remota non autenticata sui negozi Magento e Adobe Commerce, ed è stata inserita da CISA nel catalogo delle vulnerabilità sfruttate. La differenza è che StyleSmuggler colpisce il core della piattaforma, non un’estensione, e non ha una patch.
Il primo passo, prima di qualsiasi mitigazione, è verificare se il negozio è già compromesso. Applicare regole di blocco su un server infetto non serve: l’impianto è dentro e si riavvia da solo.
Gli indicatori pubblicati da Sansec e nell’elenco di Disrex, aggiornato nel corso del 5 settembre, convergono su questi elementi:
[kworker/u:8:0] di proprietà di un utente non root. Un vero thread del kernel appartiene sempre a root e non ha memoria residente. Un nome tra parentesi quadre sull’utente del sito, con memoria reale, è l’impianto. L’impianto imposta la riga di comando alla stringa letterale, quindi un controllo sul campo comm del processo non trova nulla; va letto args.~/.local/share/.gvfsd/gvfsd-user, ~/.local/share/.gvfsd/.gvfsd_<8hex>.lock, /tmp/.gvfsd_<8hex>.lock, /tmp/.kw_<random>.*/5 * * * * exec <home>/.local/share/.gvfsd/gvfsd-user, con una variante che punta a /tmp/.kw_. Su un negozio la stessa riga compariva 1.728 volte e tornava entro un secondo dalla rimozione.e315687a...a26a7 e b79dfdc1...51420). Disrex ne aggiunge uno trovato su disco in entrambi i negozi (8334b434...d06ef) e uno diverso in esecuzione in memoria su uno di essi (251fabd5...bf220). L’operatore aggiorna l’impianto in memoria: va calcolato l’hash anche di /proc/<pid>/exe.247.cdnflare[.]xyz (host di scaricamento), 99.84.67[.]186:443 (comando e controllo via WebSocket su TLS), windwsecurity[.]run:443 (shell remota). Tre domini imitano server NTP con traffico UDP sulla porta 123: ntp.timesysnc[.]net, time.microsft[.]run, pool.microsft[.]studio. Le imitazioni di Microsoft sono evidenti e vanno cercate nei log DNS.88.216.72[.]181 (Sansec, vista su più vittime), 5.181.86[.]133 e 91.238.181[.]19 (Disrex, traffico in massa). La seconda è la sorgente quasi esclusiva della seconda ondata, nel pomeriggio del 5 settembre.POST /graphql?styles[...]= con codifica percentuale; POST /paypal/transparent/response/ con codice PHP nella stringa di query. C’è poi la richiesta ordinaria GET /customer/section/load/, che nella variante osservata da Disrex portava il payload nell’intestazione User-Agent. Le richieste di exploit arrivano con user agent python-requests (2.15.0 nella prima ondata, 2.32.4 nella seconda), mai con un browser.MG<20 hex>::...::/MG<20 hex>. La sua presenza nei log prova che il codice è stato eseguito, non solo inviato. Un secondo segnale è un TypeError di array_merge() con argomento intero in system.log, subito dopo l’include: indica che l’exploit è riuscito. La variante più silenziosa restituisce un array vuoto e non lascia traccia.Tre avvertenze emerse sul campo meritano attenzione. Primo: il controllo pubblicato da Sansec cerca X_TRACE_ in var/report/. Entrambe le infezioni gestite da Disrex passavano da var/log/system.log e sarebbero sfuggite; vanno ispezionate entrambe le cartelle. Secondo: l’intestazione di innesco è cambiata nella stessa giornata, da X-TRACE-<10 hex> al mattino a X-<12 hex> al pomeriggio, con valore rigenerato a ogni richiesta. Una rilevazione ancorata alla stringa letterale è diventata cieca in un giorno: la ricerca deve intercettare la forma. Terzo: su uno dei due negozi l’impianto non ha aperto alcuna connessione in uscita. Ha letto le sessioni Magento dall’istanza Redis locale con 28 connessioni a 127.0.0.1:6379. Due catture di traffico di oltre 200 MB ciascuna non contenevano un solo pacchetto verso gli indirizzi noti. L’assenza di traffico sospetto non prova nulla.
Sugli scanner c’è un dato discordante, da riportare come tale. Sansec raccomanda il proprio eComscan e ha rilasciato la versione 1.9.7, che termina i processi per i clienti Shield. Disrex riferisce invece che su uno dei negozi infetti lo scanner, con i controlli su processi in background e attività pianificate attivi, ha dato esito pulito con 1.728 righe cron malevole presenti. Disrex non indica versione e orario dell’esecuzione. In ogni caso gli scanner puntati sulla sola cartella web non vedono un impianto installato un livello sopra.
Un segnale indiretto: raffiche inattese di email “Payment Transaction Failed Reminder” sono un motivo per indagare, anche se pagamenti rifiutati legittimamente generano la stessa notifica.
In assenza di una correzione del produttore, le opzioni si dispongono su tre livelli. L’ordine riflette la robustezza. La ragione sta nella struttura della catena come la descrive Disrex. Il punto di ingresso non può essere protetto in modo pulito, perché il codice che elabora il testo iniettato prepara anche ogni email transazionale. Un controllo lì romperebbe le conferme d’ordine. Restano il blocco del punto di uscita e le misure che non dipendono dalla conoscenza della vulnerabilità.
Livello 1: misure di sistema indipendenti dalla catena. Sono le due misure che Disrex mette davanti a ogni altra regola del proprio repository. Su uno dei negozi compromessi le prime quattro delle sei funzioni tentate dal dropper erano disabilitate, ma proc_open no. È stata quella ad avviare l’impianto, e open_basedir non ha contenuto il processo figlio, che una volta avviato gira fuori da PHP. Una lista disable_functions che ferma cinque funzioni su sei non ferma nulla. Le misure sono quindi due: aggiungere proc_open e le altre cinque funzioni a disable_functions in PHP; montare /tmp, /var/tmp e /dev/shm con opzione noexec, così che un binario scaricato non possa essere eseguito. Entrambe vanno provate in staging, perché alcune estensioni legittime dipendono da proc_open.
Livello 2: disattivazione temporanea di GraphQL. È il consiglio interinale di Sansec per i negozi che non usano Shield. Le vetrine headless e PWA richiedono GraphQL; la maggior parte delle vetrine classiche e Hyvä non lo usa. Un conteggio delle richieste POST /graphql nei log di accesso dice se la disattivazione è praticabile. È la strada scelta anche da alcuni fornitori di hosting. Nexcess, marchio di Liquid Web, ha comunicato la sera del 5 settembre un blocco completo delle richieste GraphQL su tutti gli ambienti Magento e Adobe Commerce gestiti. Ha avvertito che le vetrine headless e PWA possono risentirne. Un esercente italiano su hosting gestito potrebbe quindi trovarsi con GraphQL bloccato senza averlo deciso: va verificato con il fornitore.
Livello 3: patch e regole non ufficiali. Tre soggetti hanno pubblicato mitigazioni il 5 settembre:
ArrayScanner, ClassesScanner, XmlInterceptorScanner), che impedisce loro di girare fuori dalla riga di comando. Il guard è disponibile anche come patch composer che si riapplica a ogni deploy. Secondo Disrex, la patch è stata verificata in prova a secco sui tag 2.4.6, 2.4.7, 2.4.8 e 2.4.9. È stata poi applicata su installazioni attive 2.4.7-p2 e 2.4.8-p4, con setup:di:compile e vetrina funzionanti. Il repository dichiara i propri limiti. È stato scritto con assistenza di intelligenza artificiale durante un incidente e non è stato revisionato. Le regole Apache non sono mai state eseguite su un server Apache reale; nulla è stato provato su hosting condiviso, Docker o pannelli di controllo. Una prova su un negozio attivo ha mostrato che le regole per il server web si aggirano spostando gli stessi parametri nel corpo di una POST. Fermano la campagna come è condotta oggi, non la vulnerabilità. Disrex avverte che il guard non è una correzione completa, perché in Magento esistono altri punti di include non proteggibili allo stesso modo.{{block}} dei template email rifiuta i blocchi di backend. Il generatore di URL delle righe di griglia valida la classe prima di costruirla. I tag di apertura PHP nei rapporti di errore delle Web API vengono spezzati. L’ultima release (2.0.0) aggiunge il rifiuto di template caricati da stream wrapper o percorsi con byte nullo e rimuove un override di un resolver PayPal presente nella prima versione. L’autore avverte che il pacchetto cambierà mentre prova nuovi livelli di mitigazione e che va letto il changelog prima di ogni aggiornamento. Precisa che si tratta di irrobustimento e non di correzione: la vulnerabilità resta aperta.Va detto con chiarezza: né Sansec né Adobe hanno confermato che gli scanner DI siano il punto in cui la catena termina. Chi applica queste patch lo fa a proprio rischio, sulla base di una ricostruzione indipendente non convalidata dal produttore.
Se il negozio è già compromesso. La guida di pulizia di Disrex fissa un ordine. Prima confermare e preservare le prove; poi contenere, cercare altre persistenze e ruotare i segreti; quindi decidere se pulire o ricostruire. Le mitigazioni si applicano solo alla fine. Tre regole contano più delle altre. Rimuovere la voce cron prima di terminare il processo, perché il processo la ripristina. Non riavviare la macchina, perché la copia in /proc può essere l’unico binario superstite. Non eseguire composer install come pulizia, perché sovrascrive le date di modifica che documentano cosa è stato toccato.
La ricerca va estesa oltre il crontab: timer systemd anche per utente, at, auto_prepend_file, file PHP in pub/media, chiavi SSH sconosciute. Dentro Magento: account amministrativi non riconosciuti, integrazioni e token API, script iniettati in core_config_data, blocchi CMS modificati. Segue lo svuotamento delle sessioni, che l’impianto leggeva. Vanno poi ruotate la crypt/key in app/etc/env.php, la password del database, tutte le password amministrative, le chiavi API dei fornitori di pagamento e ogni altra credenziale in quel file. Disrex indica anche quando la ricostruzione è preferibile alla pulizia. I casi sono quattro: negozio non sotto controllo di versione; file modificati non spiegabili in vendor/ o app/code/; impianto attivo per giorni; impossibilità di datare l’inizio della compromissione.
Un ultimo elemento sulla campagna. L’elenco di Disrex, nella revisione più recente, conta 27 indirizzi sorgente distinti su tre negozi e due ondate. La cifra era 26 nella prima versione ed è stata corretta; il README dello stesso repository riporta 28. Tre indirizzi appartengono a infrastrutture di hosting che inviavano in massa; il resto è un insieme di proxy residenziali con due-sei richieste ciascuno. Disrex raccomanda di non bloccare in blocco gli indirizzi residenziali: sono connessioni di consumatori affittate o compromesse, e il blocco costerebbe clienti reali. Bloccare il solo indirizzo citato nell’avviso Sansec avrebbe fermato meno di un quarto del traffico osservato. È un dato di una sola fonte, ma è coerente con l’infrastruttura distribuita tipica delle campagne di web skimming degli ultimi anni.
Questa sezione ha finalità informativa e non sostituisce il parere di un legale.
Notifica al Garante. L’articolo 33 del GDPR impone al titolare di notificare la violazione all’autorità di controllo senza ingiustificato ritardo e, ove possibile, entro 72 ore da quando ne è venuto a conoscenza. L’obbligo cade se è improbabile che la violazione presenti un rischio per i diritti e le libertà delle persone fisiche. Il nodo, in una situazione come questa, è il momento della “conoscenza”. Le Linee guida 9/2022 dell’EDPB (versione 2.0, adottata il 28 marzo 2023) lo definiscono al paragrafo 31. Il titolare è a conoscenza quando ha un ragionevole grado di certezza che un incidente di sicurezza abbia compromesso dati personali. Il paragrafo 34 ammette un breve periodo di indagine iniziale, durante il quale il titolare non è ancora “a conoscenza”. Il paragrafo 36 precisa però che le verifiche preliminari vanno completate poco dopo il primo allarme, e possono richiedere più tempo solo in casi eccezionali. Il paragrafo 40 aggiunge che chi non agisce tempestivamente e poi scopre la violazione rischia la contestazione di mancata notifica. L’esempio 3 del paragrafo 33 descrive il caso di specie: un titolare rileva una possibile intrusione, controlla i sistemi, conferma la compromissione dei dati e da quel momento è a conoscenza.
Tradotto in pratica. Un esercente che rileva gli indicatori sopra descritti ha superato la soglia, perché l’impianto leggeva le sessioni e aveva accesso a credenziali e chiavi di pagamento; le 72 ore partono da lì. Un esercente che non rileva indicatori, ma non può escludere l’esposizione tra il 4 settembre e l’applicazione delle mitigazioni, si trova nella fase di indagine. Deve avviarla subito, documentarla con date e attività svolte e chiuderla in fretta. L’articolo 33, paragrafo 5, impone di registrare ogni violazione; il paragrafo 125 delle Linee guida chiede di motivare per iscritto anche la decisione di non notificare. L’articolo 33, paragrafo 4, consente la notifica per fasi. Il paragrafo 57 delle Linee guida indica proprio gli incidenti informatici che richiedono analisi forense come il caso tipico in cui il quadro completo manca nelle 72 ore. Il paragrafo 60 ricorda infine che non c’è sanzione per aver notificato un incidente che poi si rivela non essere una violazione.
Comunicazione agli interessati. L’articolo 34 richiede la comunicazione agli interessati quando la violazione è suscettibile di presentare un rischio elevato. La compromissione di un server che gestisce pagamenti rientra quasi sempre in questa categoria. L’esempio ii dell’allegato B delle Linee guida (attacco a un servizio online con esfiltrazione di dati) prevede la notifica all’autorità e, a seconda della gravità, agli interessati. L’esenzione per dati cifrati (paragrafi 76-78) vale solo se la chiave non è stata compromessa. È da escludere quando la crypt/key di Magento era leggibile dall’utente del sito con cui girava l’impianto. Le stesse Linee guida avvertono che, se la chiave risulta compromessa in un secondo momento, l’obbligo di notifica si riattiva.
Ripartizione delle responsabilità. Nella filiera tipica di un e-commerce italiano l’esercente è titolare del trattamento. L’agenzia che gestisce l’installazione e il fornitore di hosting sono di regola responsabili ai sensi dell’articolo 28. Due conseguenze pratiche. La prima: l’articolo 33, paragrafo 2, obbliga il responsabile a informare il titolare senza ingiustificato ritardo. Il paragrafo 44 delle Linee guida chiarisce che il responsabile non deve prima valutare il rischio; deve solo accertare che la violazione c’è stata e avvisare. Da quel momento il titolare è considerato a conoscenza. Un’agenzia che ha visto gli indicatori sui server dei clienti e non lo ha comunicato ha quindi una responsabilità autonoma. L’esempio vii dell’allegato B (fornitore di hosting che scopre un difetto nel proprio codice) mostra che l’obbligo scatta anche prima di aver accertato lo sfruttamento effettivo.
La seconda: il contratto di servizio è il luogo in cui si decide chi doveva applicare le mitigazioni e in quanto tempo. Molti contratti prevedono l’applicazione delle patch ufficiali entro un certo termine, ma tacciono sul caso in cui una patch ufficiale non esista. Chi decide se applicare una patch di terze parti non revisionata? Chi risponde se quella patch rompe il negozio, o se la mancata applicazione lo espone? Sono domande che i contratti in essere raramente affrontano e che questa vicenda rende urgenti. L’articolo 82, sul diritto al risarcimento, ripartisce la responsabilità civile tra titolare e responsabile in base al rispettivo contributo al danno.
PCI DSS. Per chi è soggetto allo standard, la versione 4.0.1 richiede al requisito 6.3.3 che le patch per le vulnerabilità critiche siano installate entro un mese dal rilascio. Il requisito presuppone una patch. In sua assenza operano il requisito 6.3.1 (identificazione delle vulnerabilità tramite fonti riconosciute, compresi gli avvisi dei CERT, e loro classificazione per rischio) e i controlli compensativi. I requisiti 6.4.3 e 11.6.1 sono qualificati dallo standard come buone pratiche fino al 31 marzo 2025 e obbligatori da quella data. Il primo impone autorizzazione, integrità e inventario di tutti gli script caricati nelle pagine di pagamento. Il secondo richiede un meccanismo che rilevi le modifiche non autorizzate alle intestazioni HTTP e agli script così come li riceve il browser del cliente, eseguito almeno ogni settimana. Sono esattamente i controlli che intercetterebbero uno skimmer inserito dopo una compromissione via StyleSmuggler. Il requisito 12.10.1 impone infine un piano di risposta agli incidenti, da attivare al primo indicatore.
NIS2. Il singolo negozio online non rientra tra i soggetti del D.Lgs. 138/2024. L’allegato II del decreto include invece i fornitori di mercati online tra i fornitori di servizi digitali. Un fornitore di hosting che gestisce molti e-commerce può rientrare nel perimetro come fornitore di servizi cloud o di data center (allegato I, settore 8, infrastrutture digitali). Un’agenzia che amministra le installazioni Magento dei clienti può rientrarvi come fornitore di servizi gestiti o di servizi di sicurezza gestiti (allegato I, settore 9, gestione dei servizi TIC business-to-business). Restano fermi i criteri dimensionali e la registrazione presso l’ACN. In quel caso l’articolo 25 prevede tre adempimenti per gli incidenti significativi. Una pre-notifica al CSIRT Italia entro 24 ore dalla conoscenza; una notifica entro 72 ore con valutazione iniziale e indicatori di compromissione; una relazione finale entro un mese. Il comma 3 precisa che la notifica non espone chi la effettua a una responsabilità maggiore di quella derivante dall’incidente. I commi 9 e 10 prevedono la comunicazione ai destinatari dei servizi sia degli incidenti sia delle minacce significative, con le misure di mitigazione adottabili. Per un fornitore in perimetro, StyleSmuggler è una minaccia significativa da comunicare ai clienti anche prima di qualsiasi compromissione accertata.
La release di sicurezza di Adobe dell’8 settembre è il primo momento in cui il quadro può cambiare. Tre scenari sono possibili. La release include una correzione con relativo CVE. Oppure non la include, e Adobe pubblica un bollettino fuori ciclo nei giorni successivi. Oppure Adobe pubblica prima una soluzione temporanea ufficiale e poi la patch. In ogni caso la finestra successiva va preparata ora.
Chi ha applicato patch non ufficiali deve pianificarne la rimozione prima di installare quella del produttore. La sovrapposizione di modifiche agli stessi file può produrre conflitti o, peggio, l’illusione di aver aggiornato; la patch composer di Disrex prevede un percorso di ritorno esplicito. Chi ha disattivato GraphQL deve avere pronto il piano di riattivazione, con prove funzionali sul pagamento. Chi ha pulito un negozio compromesso deve ricordare che la patch non rimuove una backdoor già installata né invalida credenziali già sottratte. La rotazione dei segreti resta necessaria anche dopo l’aggiornamento.
Resta il punto più scomodo. Un e-commerce compromesso tra il 4 settembre e l’applicazione delle mitigazioni può aver perso dati di pagamento senza che nulla lo segnali, perché l’impianto può operare senza traffico verso indirizzi noti. Per quegli esercenti l’8 settembre non chiude l’incidente. Apre la fase in cui bisogna decidere, con i log alla mano e con un legale al fianco, se e cosa notificare.
https://www.ictsecuritymagazine.com/notizie/zero-day-magento-stylesmuggler-adobe-commerce/
Bastano un servizio SSH esposto su Internet e nessuna credenziale. Con questi soli requisiti, almeno dal 2 settembre, alcuni attaccanti prendono il controllo completo di dispositivi MikroTik RouterOS e lasciano come firma un account amministrativo chiamato ops. Lo ha confermato il 5 settembre 2026 CERT Polska, il team che ha scoperto le vulnerabilità e ha chiamato la catena “MikroTrick”. MikroTik ha pubblicato le versioni corrette su tutti i canali e raccomanda di aggiornare subito.
Il team polacco ha individuato sei vulnerabilità in RouterOS, due delle quali critiche, e ne ha coordinato la divulgazione. Combinandone due, un attaccante ottiene privilegi amministrativi completi senza autenticarsi, purché il dispositivo esponga SSH su rete pubblica. Le falle riguardano il server e il client SSH, il servizio bandwidth-test, la gestione dei certificati X.509 e l’interfaccia WebFig.
Secondo i record NVD, sono interessate tutte le release RouterOS 6.x precedenti alla 6.49.21, le 7.x precedenti alla 7.23.4 e la 7.24 precedente alla 7.24.2. I punteggi che seguono sono i CVSS 4.0 assegnati da CERT Polska, ente assegnatario delle CVE; NVD non ha ancora pubblicato una propria valutazione.
Le tre vulnerabilità principali sono:
L’elenco completo delle sei CVE è disponibile su una pagina dedicata di CERT Polska. Il team spiega di aver anticipato la pubblicazione per una ragione precisa: i pacchetti corretti erano già pubblici e il confronto tra le versioni aveva permesso alla comunità di ricostruire alcune correzioni. Non ha diffuso codice di exploit né dettagli utili ad automatizzare gli attacchi.
CERT Polska dichiara di aver ricevuto conferma che la catena MikroTrick viene usata per assumere il controllo di dispositivi con SSH esposto e che le patch bloccano gli attacchi osservati. Gli attacchi riusciti, compresa la creazione dell’account ops, provengono dall’indirizzo IP 82.192.72.4 e risalgono almeno al 2 settembre. Un secondo indirizzo, 103.102.31.18, è stato usato in tentativi di sfruttamento della stessa catena.
Nei log di RouterOS l’attacco lascia due tracce riconoscibili: un accesso fallito per l’utente -2 via SSH, seguito dalla creazione di un nuovo utente da parte di ssh:-2@<ip>. La presenza di uno qualsiasi di questi elementi va indagata subito. La loro assenza, avverte il team, non esclude un’attività non autorizzata.
Il bollettino di sicurezza MikroTik, datato 3 settembre 2026, definisce l’aggiornamento importante e afferma che la maggior parte delle configurazioni non è a rischio. Conferma che la correzione è inclusa in RouterOS 7.25beta3, 7.24.2, 7.23.4 e 6.49.21. Il 4 settembre è uscita anche la 7.23.5 per il ramo long-term: non aggiunge correzioni di sicurezza, ma risolve una regressione del DHCP IPv6 introdotta dalla 7.23.4, ed è quindi la versione a cui puntare. Il vendor non ha ancora pubblicato dettagli tecnici, per dare tempo agli amministratori di aggiornare. Per gli utenti domestici, scrive, il rischio non è immediato, ma consiglia comunque a tutti di aggiornare. CERT Polska riferisce inoltre che MikroTik, per la prima volta, ha inviato una notifica push agli utenti dell’app mobile ufficiale.
Le release corrette utilizzano anche il meccanismo Flagged, presente da tempo nel device-mode di RouterOS. All’avvio il sistema analizza la configurazione alla ricerca di segni noti di modifiche non autorizzate; disabilita le voci sospette, scrive un messaggio critico nel log e imposta lo stato “Flagged”, descritto nella pagina dedicata del manuale. CERT Polska precisa però tre cose: il meccanismo rileva solo alcune tracce; l’assenza del marcatore non prova che il dispositivo sia integro; non si può escludere che il vendor abbia corretto anche vulnerabilità ignote al team e non descritte nelle note di rilascio.
RouterOS è usato, in Italia come altrove, da operatori ISP e WISP, in reti aziendali e di PMI e in contesti edge. La catena colpisce esattamente i dispositivi che espongono SSH su Internet. Un dato di contesto, datato ma indicativo, viene dal rapporto Eclypsium del dicembre 2021: su oltre due milioni di dispositivi MikroTik con interfacce di gestione raggiungibili dalla rete, circa 300.000 risultavano vulnerabili a falle note. L’Italia figurava tra i cinque Paesi più interessati, con Cina, Brasile, Russia e Indonesia.
Al momento non risultano vittime italiane confermate pubblicamente e CSIRT Italia non ha pubblicato un avviso su questa catena. Lo stesso CSIRT era però già intervenuto sull’ecosistema MikroTik nell’ultimo anno. Il 29 ottobre 2025 ha pubblicato un alert sul componente WebFig di RouterOS e SwitchOS; il 17 gennaio 2025 un bollettino su una botnet di dispositivi MikroTik compromessi.
Un router o gateway compromesso offre all’attaccante persistenza a livello di rete, intercettazione o deviazione del traffico, tunnel verso l’esterno e movimento laterale verso i sistemi interni. È il modello, ormai documentato, dei dispositivi di rete usati come infrastruttura offensiva. Va aggiunta una considerazione normativa: gli obblighi di notifica NIS2 al CSIRT Italia sono operativi dal 15 gennaio 2026, quindi un dispositivo di frontiera compromesso può diventare rapidamente un incidente da segnalare per i soggetti in perimetro.
/system/device-mode/print. Verificare la presenza di utenti sconosciuti (in particolare ops), script, attività dello scheduler, proxy e tunnel non riconosciuti./system ssh e /system ssh-exec) verso host o reti non fidati. Sono misure temporanee che non sostituiscono la patch.Un dettaglio di metodo merita attenzione. CERT Polska riferisce di aver individuato le vulnerabilità con il supporto dei modelli GPT-5.5-cyber e GPT-5.6-sol, disponibili al team nell’ambito del programma OpenAI Government and Trust Agency Collaboration. I modelli hanno lavorato in un ambiente di ricerca agentico su un laboratorio isolato. Hanno automatizzato la creazione delle macchine di prova, il confronto tra versioni e l’analisi di RFC e codice binario. Particolarmente efficace, secondo il team, è stata la modellazione dei protocolli come macchine a stati, per verificare cosa accade quando una fase viene saltata, ripetuta o eseguita nell’ordine sbagliato.
Ogni ipotesi ha però richiesto conferma su sistemi RouterOS reali, test di controllo negativi e valutazione d’impatto da parte dei ricercatori. I modelli, conclude CERT Polska, hanno accelerato l’analisi senza sostituire la verifica umana. È una lezione coerente con quella portata al Forum ICT Security 2025 dal Politecnico di Torino sugli agenti AI applicati all’individuazione delle CVE: l’architettura dell’agente e il controllo umano pesano più del modello.
https://www.ictsecuritymagazine.com/notizie/mikrotik-mikrotrick/
Emerso ad agosto 2026, Panzer unisce un programma di affiliazione già maturo, payload per Windows, Linux, ESXi e FreeBSD e doppia estorsione. Tra le prime vittime rivendicate figurano Doimo Cucine e NTE Italia.
Nel panorama ransomware la comparsa di una nuova sigla non è, di per sé, una notizia: il ricambio è continuo e molti operatori scompaiono nel giro di poche settimane. Panzer merita attenzione per un motivo diverso: la rapidità con cui ha messo in piedi una piattaforma completa. Secondo il profilo pubblicato il 4 settembre 2026 dalla società di threat intelligence CyberXtron, il leak site del gruppo sulla rete Tor è attivo dal 5 agosto, data della prima osservazione, e in un mese ha pubblicato 16 vittime in almeno 11 Paesi.
La distribuzione geografica non ha un baricentro: tre vittime in Thailandia, due in Italia, due in Indonesia, due in Serbia e una sola in ognuno degli altri Paesi colpiti, cioè Curaçao, Corea del Sud, Spagna, Repubblica Ceca, Germania, Nigeria e Svizzera. Anche i settori sono eterogenei: la tecnologia è in testa con quattro casi, seguita dalla manifattura con tre; poi governo e difesa, agroalimentare, energia e utility, istruzione e retail. È il profilo tipico di una campagna opportunistica, guidata dagli accessi che gli affiliati riescono a procurarsi e non da una scelta mirata di Paesi o settori.
Il conteggio, peraltro, è già superato. Tre tracker indipendenti, SOCRadar, Ransomware.live e l’italiano Ransomfeed, concordano su 19 vittime al 6 settembre. Le ultime due rivendicazioni, del 3 e del 4 settembre, riguardano un ente pubblico indonesiano e un’università tedesca; dopo le 17 rivendicazioni di agosto il ritmo è rallentato, ma il gruppo resta attivo.
Sul numero di Paesi colpiti, invece, i tracker divergono: Ransomware.live ne conta 11, SOCRadar 16, e negli elenchi compaiono Portogallo, Francia e Cipro, assenti dal censimento di CyberXtron. Le differenze dipendono dai criteri di attribuzione geografica, e una stessa vittima può essere attribuita a Paesi diversi a seconda della piattaforma: il gruppo orologiero Festina, per esempio, è registrato in Spagna da Ransomfeed e in Svizzera da SOCRadar. È un’avvertenza da tenere presente ogni volta che si citano questi numeri. SOCRadar indica inoltre la Russia come Paese di origine del gruppo: un’attribuzione coerente con il divieto di colpire i Paesi della CSI, ma non confermata da altre fonti.
Le due organizzazioni italiane sono censite, con dati coincidenti, sia da Ransomware.live sia da Ransomfeed. La prima è Doimo Cucine, produttore di cucine di design con sede a Nervesa della Battaglia, in provincia di Treviso: la rivendicazione è stata rilevata il 17 agosto e, secondo la scheda di Ransomware.live, il gruppo dichiara di aver esfiltrato 30 GB di dati. La seconda è NTE Italia, società di servizi tecnici e di ingegneria per le telecomunicazioni e la sicurezza dei cantieri, con sede a Catanzaro e uffici a Roma e Catania: è comparsa sul leak site il 21 agosto e il gruppo afferma di aver sottratto 16 GB di dati, descritti come migliaia di documenti sensibili.
Una pubblicazione su un leak site resta una rivendicazione dell’attaccante, non una prova. Nessuna delle due aziende ha confermato pubblicamente l’incidente, e le rivendicazioni di un gruppo appena emerso, privo di uno storico verificabile, vanno trattate con particolare cautela fino a verifica indipendente. La comparsa di due vittime italiane in pochi giorni richiama una dinamica ricorrente nei RaaS di recente formazione: concentrare più bersagli in un breve intervallo per costruire credibilità presso i potenziali affiliati.
Il tratto più interessante di Panzer non è il malware, di cui si sa ancora poco, ma l’infrastruttura commerciale. L’operazione si presenta come un RaaS semi-aperto: gli aspiranti affiliati presentano domanda tramite un canale Tox e ottengono l’accesso al pannello di controllo solo dopo una selezione. La ripartizione dei proventi è 80/20 a favore dell’affiliato, con la quota della piattaforma trattenuta automaticamente su ogni pagamento. Le regole vietano di colpire organizzazioni nei Paesi della CSI e soggetti coinvolti in abusi su minori; gli account inattivi per più di una settimana vengono disattivati.
Il pannello di controllo descritto da CyberXtron è quello di un servizio già rodato. Comprende il monitoraggio del saldo e delle transazioni, la gestione delle build per le diverse piattaforme, con una chat di negoziazione dedicata a ogni vittima e un generatore integrato di fatture in Bitcoin, un sistema di ticket di assistenza e sotto-account per i team. La pubblicazione dei leak segue un flusso con approvazione preventiva degli operatori, conto alla rovescia e possibilità di mettere in evidenza i casi ritenuti più redditizi. Gli operatori dichiarano inoltre di sottoporre i nuovi affiliati a un monitoraggio automatico durante il primo mese, per individuare ricercatori o forze dell’ordine infiltrati.
Un investimento di questo tipo in strumenti per il reclutamento, i pagamenti e l’autotutela indica un progetto pensato per crescere attraverso operatori esterni, non un gruppo chiuso che conduce in proprio le intrusioni. È la logica del ransomware human-operated portata alle estreme conseguenze: la piattaforma fornisce strumenti e infrastruttura, gli affiliati eseguono le intrusioni. Alcuni osservatori accostano il modello a quello di VanHelsing e di altri RaaS emersi negli ultimi anni.
Sul piano tecnico il quadro è frammentario e il vettore di accesso iniziale non è stato verificato in modo indipendente. Le attività che CyberXtron associa al gruppo, con confidenza medio-bassa, comprendono il dumping delle credenziali del sistema operativo, attacchi di forza bruta, la ricognizione dei servizi di rete, il movimento laterale tramite servizi remoti e account validi, la raccolta di dati dal sistema locale, l’esfiltrazione su protocolli alternativi e la disabilitazione o manomissione degli strumenti di sicurezza. La mappatura di SOCRadar, in parte diversa, aggiunge l’esecuzione tramite interprete di comandi, la persistenza all’avvio e l’inibizione del ripristino di sistema, tecnica che prende di mira le copie shadow e i meccanismi di recupero.
Non esistono al momento indicatori di compromissione confermati, siano essi hash, indirizzi IP, domini o campioni di malware: gli unici indicatori pubblici riguardano l’infrastruttura del leak site e il canale di reclutamento. Ciò che invece dichiarano gli stessi operatori è la copertura dei payload: build per Windows, Linux, VMware ESXi e FreeBSD, con oltre quindici comandi personalizzabili, funzioni anti-rilevamento e un pannello di avvio con monitoraggio in tempo reale dell’operazione. Lo schema è quello della doppia estorsione: i dati vengono esfiltrati prima della cifratura e alcuni campioni finiscono sul leak site come prova.
Due caratteristiche rendono Panzer una minaccia concreta per il tessuto produttivo nazionale, al di là dei due casi già noti.
La prima è il supporto a ESXi. Gran parte delle medie e grandi imprese italiane concentra i propri carichi di lavoro su infrastrutture virtualizzate: compromettere un hypervisor significa cifrare in un’unica operazione decine di macchine virtuali e i servizi che vi girano, con tempi di ripristino ben più lunghi rispetto a un attacco limitato agli endpoint Windows. Le build per Linux e FreeBSD allargano ulteriormente la superficie esposta negli ambienti con parchi server misti. Non è un rischio teorico: il CSIRT Italia, nel bollettino dedicato a Qilin, ha già segnalato l’uso di tecniche mirate agli ambienti VMware ESXi da parte di un gruppo il cui impatto sistemico sul Paese è classificato come critico.
La seconda è la doppia estorsione. Backup solidi e testati restano indispensabili per la continuità operativa, ma non neutralizzano il rischio legato alla pubblicazione dei dati sottratti, con le conseguenze reputazionali, contrattuali e regolamentari che ne derivano, comprese le notifiche previste dal GDPR e, per i soggetti che rientrano nel suo ambito di applicazione, dalla NIS2.
Il contesto aggrava il quadro. Secondo Ransomfeed, al 6 settembre le rivendicazioni contro organizzazioni italiane nel 2026 sono già 212, contro le 169 dell’intero 2025, su un totale storico di 850. Nella sola settimana tra il 6 e il 13 agosto, secondo una ricostruzione ripresa anche da Bismark.it, otto gruppi diversi hanno rivendicato 15 vittime italiane. Panzer si inserisce in una fase in cui gli attaccanti puntano soprattutto sulla manifattura, già segnalata dall’ACN come bersaglio privilegiato nei distretti industriali del Nord, e sui fornitori di servizi tecnologici e di telecomunicazione: ne sono esempi NTE Italia e Retelit, quest’ultima colpita da Qilin a fine luglio.
Le raccomandazioni pubblicate da CyberXtron coincidono con le buone pratiche già consolidate contro il ransomware, ma alcune assumono un peso particolare alla luce delle caratteristiche di Panzer.
Sul fronte delle identità, la priorità è l’autenticazione a più fattori resistente al phishing su tutti gli accessi remoti, le VPN e gli account privilegiati, unita al principio del minimo privilegio e a una revisione periodica degli account amministrativi: le tecniche associate al gruppo ruotano intorno al furto e all’abuso di credenziali valide. Sul fronte architetturale, la segmentazione deve isolare dalle reti utente i controller di dominio, i sistemi di backup e, soprattutto, l’interfaccia di gestione degli hypervisor, confinando i protocolli di amministrazione remota in segmenti dedicati e monitorati.
Contro la doppia estorsione servono controlli sul traffico in uscita e il rilevamento dei trasferimenti anomali di dati: l’esfiltrazione precede la cifratura ed è la finestra più utile per intercettare l’attacco. I backup devono essere immutabili, con almeno una copia offline, isolata dalla rete, e test di ripristino regolari che verifichino l’integrità dei punti di ripristino. Il piano di risposta agli incidenti, infine, dovrebbe prevedere esplicitamente lo scenario di esposizione dei dati, con i flussi legali, regolamentari e di comunicazione pronti prima che una rivendicazione compaia online.
Panzer è ancora in fase di espansione e il suo profilo tecnico potrebbe cambiare rapidamente man mano che nuovi affiliati introducono metodi propri. Proprio per questo va trattato come una minaccia credibile e trasversale, non come un fenomeno di nicchia.
https://www.ictsecuritymagazine.com/notizie/panzer-ransomware-vittime-italiane/
Due impianti Windows analizzati da Kaspersky non usano infrastruttura propria per il comando e controllo: uno si appoggia al broker MQTT pubblico di HiveMQ, l’altro al protocollo Matrix. Le vittime documentate sono russe e non si tratta di un attacco a sistemi industriali, ma la tecnica solleva un problema di rilevamento che riguarda direttamente chi gestisce reti OT.
Il 4 settembre 2026 Kaspersky ha pubblicato su Securelist l’analisi di due backdoor che i suoi ricercatori attribuiscono al gruppo a movente finanziario noto come Toy Ghouls, indicato anche con i nomi Bearlyfy, Laboo.boo e Feral Wolf. L’attribuzione è dei team GERT e Security Services di Kaspersky e va riportata come tale.
Il gruppo è attivo dal 2025 contro organizzazioni russe. Ha iniziato appoggiandosi a strumenti disponibili pubblicamente e a builder di ransomware trapelati, quelli di Babuk e LockBit, per poi sviluppare codice proprio, tra cui il ransomware GenieLocker, in versioni per Windows, Linux ed ESXi.
I due impianti individuati all’inizio di luglio 2026 si chiamano mqtt-bird-agent 0.1.0 e matrix-bird-agent 0.1.0, e corrispondono a due eseguibili Windows, cplsupport.exe e wtass.exe. Il tratto che li rende interessanti è che nessuno dei due porta con sé un server di comando e controllo: entrambi si appoggiano a servizi e protocolli legittimi.
Un secondo elemento merita attenzione, e riguarda il modo in cui arrivano sulla macchina. La distribuzione avviene attraverso Windows Remote Management, con utilità di post-sfruttamento open source come Evil-WinRM e WinRM-fs. Il report non descrive il vettore di accesso iniziale, ma la scelta di WinRM implica che gli operatori dispongono già di credenziali amministrative quando installano l’impianto: la backdoor non è il punto di ingresso, è ciò che rende l’accesso persistente.
La persistenza si ottiene registrandosi come servizio Windows, con i nomi “cplsupport” (descritto come “Problem Reports Control Panel”) e “wtas” (“Windows Telemetry Aggregator Service”), tramite argomenti di installazione e disinstallazione. In entrambe le varianti i campi sensibili della configurazione vengono cifrati al primo avvio con ChaCha20-Poly1305, con una chiave derivata dal valore MachineGuid del registro di sistema: un accorgimento che impedisce di riutilizzare la configurazione su un’altra macchina e complica il lavoro di chi analizza il campione fuori dall’ambiente di origine. La variante MQTT conserva il file cifrato su disco; la variante Matrix lo cancella dopo il primo avvio e sposta i parametri in una chiave di registro dedicata.
Secondo Kaspersky, la variante mqtt-bird-agent comunica con broker.hivemq.com sulla porta 8883, quella standard di MQTT su TLS. Il dominio è quello del broker pubblico di HiveMQ, uno dei più noti tra quelli messi a disposizione gratuitamente per test e prototipazione: non è un server compromesso né un dominio registrato dagli attaccanti. Il report descrive quattro percorsi di scambio: uno per lo stato del sistema infetto, uno per le metriche periodiche (CPU, memoria, disco, carico, tempo di attività), uno da cui la backdoor legge i comandi e uno su cui restituisce i risultati. I comandi vengono eseguiti tramite PowerShell in modalità nascosta.
Un’annotazione di precisione: nello stesso passaggio Securelist parla di un “cluster” creato dagli attaccanti e di un piano gratuito con limiti di 100 connessioni concorrenti e 10 GB di traffico mensili. Sono esattamente le caratteristiche del piano Serverless gratuito di HiveMQ Cloud, che prevede credenziali di accesso e TLS, non quelle del broker demo aperto, che non ha né cluster né piani. Il report non scioglie l’ambiguità. La conseguenza pratica è che non si può dare per certo che il canale fosse privo di autenticazione, e che l’indirizzo effettivamente contattato potrebbe essere un sottodominio dedicato del servizio cloud piuttosto che il nome generico del broker pubblico: in entrambi i casi, comunque, la destinazione appartiene a un fornitore legittimo e ampiamente usato.
Vale la pena spiegare perché questa scelta sia efficace, al di là della gratuità.
MQTT è un protocollo publish and subscribe: il client non riceve connessioni in ingresso, si limita a stabilire una connessione uscente verso il broker e ad attendere. Non serve alcuna porta aperta sul perimetro, e il traffico ha la forma di una sessione TLS lunga verso un servizio cloud, esattamente come mille integrazioni legittime. I messaggi sono minuscoli, perché il protocollo nasce per la telemetria su reti a banda ridotta, quindi il volume non fa scattare soglie. E poiché il broker è condiviso da chiunque lo usi per test, l’indirizzo di destinazione non è un indicatore di compromissione: bloccarlo a livello di reputazione significa bloccare un servizio legittimo.
C’è però un motivo ulteriore, ed è quello che riguarda direttamente il nostro perimetro editoriale. MQTT è lo standard di fatto della telemetria industriale e dell’Internet of Things. In una rete di stabilimento, in un impianto di trattamento acque, in una flotta di dispositivi connessi, il traffico MQTT in uscita non è un’anomalia: è il funzionamento normale. Un canale di comando e controllo che parla MQTT, in quel contesto, non si nasconde tra il rumore, coincide con il rumore.
La seconda variante usa il protocollo Matrix. L’agente invia messaggi di stato e metriche con tipi di evento personalizzati, riceve comandi preceduti dal prefisso cmd: da un account chiamato “panel-bot” e li esegue attraverso la riga di comando di Windows, non PowerShell. Accetta inoltre un’istruzione di configurazione che regola l’intervallo di invio delle metriche, in una finestra che va da cinque secondi a un’ora; il valore viene salvato nel registro. Le risposte tornano come eventi di un tipo dedicato.
Qui però la somiglianza con il caso MQTT si ferma, e conviene dirlo chiaramente perché diverse riprese della notizia stanno appiattendo le due cose. Il server Matrix utilizzato è sotto il controllo degli attaccanti, raggiungibile a un dominio che richiama il nome del client Element. Non c’è quindi abuso di un servizio di terzi: c’è l’uso di un protocollo legittimo e federato su infrastruttura propria. È mimetismo di protocollo, non parassitismo di servizio.
La distinzione conta per chi deve difendersi. Nel caso MQTT il dominio di destinazione è inutilizzabile come indicatore, perché legittimo; nel caso Matrix il dominio è un indicatore valido e bloccabile, ed è l’analisi comportamentale a essere più difficile, perché il traffico Matrix cifrato è opaco per definizione.
Un’osservazione di prospettiva, che è nostra e non del report. Matrix sta guadagnando terreno nelle amministrazioni pubbliche europee proprio come alternativa sovrana alle piattaforme di messaggistica statunitensi, e il tema della sovranità digitale ne sta accelerando l’adozione. Nelle organizzazioni che lo hanno introdotto, il traffico Matrix passerà presto dall’essere un’anomalia all’essere ordinario. Vale per Matrix ciò che vale già oggi per MQTT negli impianti industriali: la protezione offerta dall’anomalia statistica ha una scadenza, e coincide con il momento in cui la tecnologia diventa diffusa.
Poiché l’angolo più interessante riguarda le reti industriali, è necessario essere precisi su ciò che il report documenta e su ciò che non documenta, altrimenti l’analisi si trasforma in allarmismo.
Non si tratta di un attacco a sistemi di controllo industriale. Gli impianti girano su Windows, vengono installati come servizi dopo che gli attaccanti hanno già ottenuto privilegi amministrativi, ed eseguono comandi tramite PowerShell o riga di comando: è una backdoor IT, non un malware progettato per interagire con logiche di processo. Le vittime documentate sono organizzazioni russe, e il report non individua settori specifici né fornisce un numero di vittime.
Il motivo di interesse non è quindi ciò che è accaduto, è ciò che la tecnica rende possibile. Un canale di comando e controllo su MQTT esiste ora, è documentato e funziona. Il giorno in cui un impianto simile venisse installato su un sistema di una rete dove MQTT è traffico normale, la difficoltà di rilevamento non sarebbe teorica. È un’osservazione prospettica, e come tale va presa: nessuna delle fonti disponibili afferma che ciò sia già avvenuto.
Il primo punto è il più controintuitivo, e riguarda la priorità. Poiché la distribuzione avviene via WinRM con strumenti noti, il momento in cui questa catena è più visibile non è quello del comando e controllo, è quello che lo precede. Sul lato Windows i segnali sono ordinari e già disponibili: la registrazione di un nuovo servizio (evento 7045 nel registro System), l’attività nel canale Microsoft-Windows-WinRM/Operational su macchine che non dovrebbero ricevere sessioni remote, connessioni in ingresso sulle porte 5985 e 5986 da postazioni che non appartengono al team di amministrazione, e la scrittura nelle directory cplsupport e SynapseAgent sotto ProgramData. Chi ha un buon rilevamento sulle attività amministrative anomale intercetta la catena prima che il canale MQTT entri in funzione, e per la maggior parte delle organizzazioni questo è l’investimento con il ritorno migliore.
Sul canale, le indicazioni utili sono di natura diversa da quelle a cui si è abituati, e vanno lette con la mappa dell’impianto davanti.
In un’architettura industriale ordinata, i client MQTT stanno in posti prevedibili: gateway e dispositivi edge al livello 2 del modello Purdue, sistemi di raccolta dati e historian al livello 3, un broker in zona demilitarizzata industriale che fa da unico punto di contatto verso l’IT e il cloud. Una connessione MQTT in uscita da una postazione Windows di livello 3 o 4, e a maggior ragione da un server di dominio o da una workstation di ufficio, non ha una funzione operativa che la giustifichi. Il primo strumento non è quindi un sensore di rete: è l’inventario dei client autorizzati, per zona, con l’indicazione del broker a cui ciascuno deve parlare. È lo stesso principio di zone e conduit di IEC 62443-3-2 applicato a un protocollo che spesso resta fuori dal disegno perché considerato “solo telemetria”.
Il secondo strumento sono i topic. Negli impianti che adottano la specifica Sparkplug B, la struttura è fissa: spBv1.0/<gruppo>/<tipo di messaggio>/<nodo>/<dispositivo>, con un vocabolario chiuso di tipi (NBIRTH, DDATA, NDEATH e pochi altri) e payload binario Protobuf. Anche dove Sparkplug non è in uso, quasi tutti gli impianti hanno una convenzione di denominazione per sito, linea e macchina. Un topic che non appartiene a nessuna di queste gerarchie, con un identificativo opaco al primo livello e percorsi come status, metrics, cmd/req e cmd/res, è riconoscibile a colpo d’occhio da chi conosce la convenzione, molto più di quanto lo sia dal volume o dalla frequenza.
Qui però va detto un limite che il report non discute. Sulla porta 8883 il traffico è cifrato in TLS, e i topic non sono visibili a chi ascolta passivamente sulla rete. Le piattaforme di monitoraggio OT che analizzano il traffico da una porta SPAN riconoscono MQTT in chiaro sulla 1883 e ne estraggono i topic; su TLS vedono l’handshake, il nome del server nell’estensione SNI, il certificato e il ritmo delle sessioni, nient’altro. La visibilità sui topic si recupera in due modi soltanto: sul broker, se è interno e registra le connessioni e le sottoscrizioni, oppure sull’host, con la telemetria di processo che mostra quale eseguibile ha aperto la connessione. Nel caso in esame, un servizio registrato come “Problem Reports Control Panel” che apre una sessione TLS persistente verso un broker MQTT è un’anomalia leggibile sull’endpoint anche senza vedere un solo byte del contenuto.
Resta il ritmo, che è osservabile anche in TLS. Un sensore industriale pubblica su evento o per eccezione, con cadenze legate al processo; un impianto di comando e controllo invia metriche a intervallo fisso e interroga il canale con regolarità. Sulla durata di ore o giorni, la differenza è misurabile.
Sul piano architetturale la misura che chiude il problema alla radice è nota e poco applicata: i dispositivi di una rete industriale dovrebbero parlare con un broker interno, con autenticazione mutua tramite certificati, e la zona OT non dovrebbe avere alcuna via verso broker pubblici su internet. L’eccezione tipica, e pericolosa, è la manutenzione remota dei fornitori di macchine, che spesso passa proprio da broker cloud del costruttore: va censita e incanalata attraverso la zona demilitarizzata, non tollerata come traffico di fondo. È lo stesso ragionamento di segmentazione tra IT e OT che si applica agli altri protocolli di campo. Il caso polacco della APN privata che nessuno sorvegliava ha mostrato poche settimane fa che cosa succede quando un canale considerato tecnico e innocuo resta fuori dal perimetro di monitoraggio.
Restano infine gli indicatori pubblicati nel report: le hash dei due eseguibili, le chiavi di registro sotto HKLM\Software\synapse e HKLM\Software\SynapseAgent, e la richiesta verso un servizio pubblico di geolocalizzazione degli indirizzi IP che entrambe le varianti effettuano all’avvio. Quest’ultima, per un sistema che non ha alcuna ragione di sapere in quale Paese si trova, è un segnale semplice e sorprendentemente efficace.
Il dato di fondo di questa vicenda va oltre i due campioni analizzati. Un gruppo criminale che rinuncia a infrastruttura propria in favore di servizi e protocolli legittimi ottiene tre vantaggi in una volta sola: costi di gestione quasi nulli, resistenza ai takedown, perché non c’è un server da sequestrare, e una superficie di attribuzione molto più povera, perché non ci sono registrazioni di dominio, hosting o pagamenti da seguire a ritroso.
È la stessa direzione che si osserva nell’abuso di piattaforme cloud, di servizi di collaboration e di repository pubblici come canali di comando e controllo. La differenza, qui, è che il servizio scelto appartiene al mondo della telemetria industriale, un’area in cui la maturità del monitoraggio è mediamente inferiore a quella dell’IT e in cui l’analisi del traffico è ostacolata da vincoli di disponibilità che non ammettono interruzioni.
Per chi difende, la lezione non è aggiungere un dominio a una lista di blocco. È accettare che l’elenco dei canali plausibili per un comando e controllo coincide ormai con l’elenco dei servizi che l’organizzazione usa legittimamente, e costruire il rilevamento su questa premessa invece che sulla reputazione delle destinazioni.
https://www.ictsecuritymagazine.com/notizie/mqtt-matrix-command-control-backdoor-toy-ghouls/