La Quadrature du Net

2026-07-06 15:18:10

La Quadrature du Net recrute un·e juriste pour décembre 2026 ou janvier 2027 ! Nous cherchons sur Paris une personne avec une expérience préalable, professionnelle ou militante. Nous avons besoin de quelqu'un capable de vulgariser nos sujets, d'appuyer les autres salarié·es et membres, qui pourra transformer des sujets juridiques en objets politiques, et nous privilégions les profils militants. ⬇️

laquadrature.net/la-quadrature…

#JeRecrute

La Quadrature du Net recherche un·e juriste pour rejoindre son équipe salariée !

Nous recherchons une personne ayant une formation de juriste (qu’il s’agisse de droit public, droit privé, droit pénal, droit international, etc.

^{La Quadrature du Net}

Spcnet.it

2026-08-25 07:18:24

Tuning del kernel Linux con sysctl: i parametri che contano davvero in produzione

Chiunque gestisca server Linux in produzione, prima o poi, si scontra con lo stesso muro: l’hardware non è il collo di bottiglia, lo sono i valori di default del kernel. Un server con dischi NVMe e una scheda di rete da 10 Gbps che fatica a superare poche centinaia di connessioni simultanee, o che soffre di latenza inspiegabile sotto carico, nella stragrande maggioranza dei casi non ha un problema di risorse: ha un problema di tuning.

Il kernel Linux espone centinaia di parametri regolabili a runtime tramite l’interfaccia sysctl, che agisce sull’albero /proc/sys/. Sono impostazioni pensate per andare bene “in media” su qualunque macchina, dal Raspberry Pi al server con 512 GB di RAM. Per un ambiente di produzione, però, “in media” spesso non basta. Vediamo quali parametri contano davvero, perché, e come applicarli senza rischiare di rompere il sistema.

Come funziona sysctl

Prima di toccare qualunque valore è utile ripassare i comandi base. sysctl permette di leggere e modificare i parametri kernel senza riavviare la macchina:

# Elencare tutti i parametri disponibili
sysctl -a

# Leggere un singolo parametro
sysctl net.ipv4.tcp_syncookies

# Modificarlo temporaneamente (non sopravvive al riavvio)
sudo sysctl -w net.ipv4.tcp_syncookies=1

Per rendere le modifiche permanenti, la pratica corretta è creare un file dedicato sotto /etc/sysctl.d/ — evitando di editare direttamente /etc/sysctl.conf, che su molte distribuzioni convive male con i pacchetti che installano le proprie regole:

sudo nano /etc/sysctl.d/99-tuning.conf
sudo sysctl --system   # applica tutti i file in /etc/sysctl.d/

Rete: buffer TCP e gestione delle connessioni

Sui server con traffico sostenuto, i buffer TCP di default sono quasi sempre troppo piccoli. Il kernel alloca dinamicamente memoria per i socket entro i limiti impostati da questi tre valori (minimo, default, massimo, in byte):

net.ipv4.tcp_rmem = 4096 87380 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864

Alzare il massimo a 64 MB ha senso soprattutto su link ad alta banda e alta latenza (data center distanti, CDN, replica di database geografica), dove il bandwidth-delay product richiede finestre TCP più ampie per saturare il collegamento.

Altrettanto importante è la gestione della coda di connessioni in ingresso, che su un server esposto a picchi di traffico determina quante richieste vengono accettate prima di iniziare a scartarle:

net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 16384
net.ipv4.tcp_syncookies = 1

somaxconn in particolare va allineato al backlog configurato lato applicazione (nginx, HAProxy, il socket listener della tua app .NET o Node): se l’applicazione chiede una coda più grande di quella permessa dal kernel, il valore effettivo resta quello più basso.

Attivare BBR come algoritmo di congestion control

Il cambiamento con il rapporto costo/beneficio più alto per la maggior parte dei server moderni è probabilmente il passaggio da CUBIC a BBR come algoritmo di controllo della congestione. CUBIC reagisce alla perdita di pacchetti: aumenta la finestra di invio finché non rileva un drop, poi la dimezza. È un approccio reattivo che su reti con perdita “di fondo” non dovuta a congestione (Wi-Fi, mobile, certi link satellitari) penalizza inutilmente il throughput.

BBR, sviluppato da Google e stabile nei kernel a partire dalla serie 4.9, funziona in modo diverso: stima attivamente il bandwidth-delay product del percorso di rete e modula l’invio di conseguenza, senza aspettare la perdita di pacchetti come segnale. Sui kernel 5.15 e 6.x l’implementazione è ulteriormente raffinata (il set di funzionalità informalmente indicato come “BBRv3”), ma non serve aggiornare il kernel apposta: se hai già un kernel recente, BBR c’è già, va solo abilitato.

# Verifica gli algoritmi disponibili
sysctl net.ipv4.tcp_available_congestion_control

# Se necessario, carica il modulo
sudo modprobe tcp_bbr
echo tcp_bbr | sudo tee /etc/modules-load.d/tcp-bbr.conf

E nel file di configurazione:

net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq

Il secondo parametro non è opzionale: BBR è stato progettato e testato insieme alla queue discipline fq (fair queue con pacing), e usarlo con la pfifo_fast di default riduce buona parte del beneficio. Dopo l’attivazione, verifica con:

sysctl net.ipv4.tcp_congestion_control
ss -tin | grep bbr

Memoria: swap, cache e writeback

Il secondo fronte dove i default fanno più danni è la gestione della memoria, in particolare su server con molta RAM dedicati a database o applicazioni in-memory.

vm.swappiness = 10
vm.vfs_cache_pressure = 50

swappiness (range 0-200, default 60) determina quanto aggressivamente il kernel sposta pagine di memoria su swap invece di liberare cache. Un valore basso come 10 dice al kernel di preferire fortemente la RAM fisica e di ricorrere allo swap solo quando davvero necessario — comportamento quasi sempre desiderabile su un server con database, dove uno swap-in inatteso su una query critica si traduce in latenza a due cifre percentuali più alta. vfs_cache_pressure più basso del default (100) fa sì che il kernel trattenga più a lungo la cache di metadati e dentry, utile su filesystem con molti file piccoli.

Altrettanto rilevante è il comportamento di scrittura delle pagine “sporche” (dirty), cioè modificate in memoria ma non ancora sincronizzate su disco:

vm.dirty_ratio = 10
vm.dirty_background_ratio = 5
vm.dirty_expire_centisecs = 1500
vm.dirty_writeback_centisecs = 250

Con i default (rispettivamente 20 e 10, spesso più alti su alcune distribuzioni), un server con molta RAM può accumulare diversi gigabyte di dati non ancora scritti su disco prima che il kernel forzi il flush — e quando lo fa, l’intero sistema può bloccarsi per secondi mentre scrive tutto in una volta. Abbassare le soglie distribuisce il lavoro di scrittura in modo più uniforme, a costo di un overhead I/O leggermente maggiore ma costante. Su macchine con centinaia di GB di RAM, conviene passare dai valori percentuali a limiti assoluti in byte (vm.dirty_bytes, vm.dirty_background_bytes), perché una percentuale del 10% su 512 GB di RAM è comunque troppo.

File descriptor e limiti di sistema

Un errore classico su server che gestiscono molte connessioni concorrenti (web server, message broker, database con molti client) è l’esaurimento dei file descriptor disponibili:

fs.file-max = 2097152
fs.nr_open = 1048576
fs.inotify.max_user_watches = 524288

Quest’ultimo parametro merita attenzione particolare: inotify.max_user_watches troppo basso è la causa più comune dell’errore “too many open files” riportato da strumenti come Webpack dev server, editor con file watching, o sistemi di sincronizzazione che monitorano grandi alberi di directory — non ha nulla a che fare con i socket di rete, ma con il numero di file che il kernel può tenere sotto osservazione per notifiche di modifica.

Sicurezza di rete

Un piccolo set di parametri riduce la superficie d’attacco a livello di stack di rete senza impatto sulle prestazioni:

net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.log_martians = 1

rp_filter (reverse path filtering) merita una nota: impostato a 1 (strict mode) rifiuta pacchetti il cui indirizzo sorgente non è raggiungibile tramite l’interfaccia su cui sono arrivati, mitigando IP spoofing. È la scelta giusta per la maggior parte dei server, ma su macchine con routing asimmetrico — tipicamente setup multihomed, alcune configurazioni VPN o BGP — va impostato a 2 (loose mode), altrimenti si rischia di scartare traffico legittimo.

Un parametro storico da NON usare

Vale la pena segnalarlo esplicitamente perché gira ancora in vecchie guide copiate e incollate da un blog all’altro: net.ipv4.tcp_tw_recycle è stato rimosso dal kernel a partire dalla versione 4.12 perché causava problemi seri dietro NAT (connessioni rifiutate in modo intermittente e difficile da diagnosticare). Se lo trovate in un file sysctl.conf ereditato da un vecchio sistema, va rimosso: su kernel recenti l’impostazione viene semplicemente ignorata, ma la sua presenza è un segnale che quella configurazione non è stata rivista da anni.

Applicare e verificare

Mettendo insieme i parametri discussi in un unico file di configurazione:

# /etc/sysctl.d/99-tuning.conf

## Rete: buffer TCP
net.ipv4.tcp_rmem = 4096 87380 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864

## Rete: congestion control
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq

## Rete: gestione connessioni
net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 16384
net.ipv4.tcp_syncookies = 1

## Memoria
vm.swappiness = 10
vm.vfs_cache_pressure = 50
vm.dirty_ratio = 10
vm.dirty_background_ratio = 5

## File descriptor
fs.file-max = 2097152
fs.inotify.max_user_watches = 524288

## Sicurezza
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.log_martians = 1

Dopo l’applicazione con sudo sysctl --system, alcuni controlli utili per confermare che tutto sia entrato in vigore:

sysctl net.ipv4.tcp_congestion_control
cat /proc/sys/fs/file-nr
cat /proc/meminfo | grep -i dirty
sudo dmesg | tail -20

Conclusione

Nessuno di questi parametri va applicato alla cieca copiando un file da internet, incluso questo. Ogni ambiente ha un profilo di carico diverso — un database transazionale, un reverse proxy ad alto traffico e un batch processor hanno esigenze di memoria e rete molto differenti — e il modo corretto di procedere è cambiare pochi parametri alla volta, misurare, e tenere traccia di cosa è stato modificato e perché, magari versionando il file sysctl.d insieme al resto della configurazione infrastrutturale. Il vantaggio di sysctl è proprio questo: ogni modifica è reversibile a runtime, il che rende il tuning un processo iterativo e sicuro invece che un salto nel buio a ogni riavvio.

Fonte originale: Linux Kernel Parameters Tuning for Better Performance, LinuxBlog.io.

Linux Kernel Parameters Tuning for Better Performance | LinuxBlog.io

Learn how to tune Linux kernel parameters using sysctl and /proc/sys for better network throughput, memory management, file I/O, and server security. Includes a ready-to-use baseline config.

^{Hayden James (LinuxBlog.io)}

Spcnet.it

2026-08-24 10:56:06

BTR Reforged: come il driver firmato di Defender può cancellare le difese di Windows all’avvio

Un driver che Windows non può bloccare

Per anni la regola d’oro della difesa contro gli attacchi BYOVD (Bring Your Own Vulnerable Driver) è stata semplice: se un driver firmato è vulnerabile, lo si aggiunge alla Microsoft Vulnerable Driver Blocklist e lo si blocca via Windows Defender Application Control (WDAC) o HVCI. Il problema è cosa succede quando il driver “vulnerabile” non è di terze parti, ma fa parte di Windows Defender stesso, ed è necessario al suo funzionamento.

È esattamente lo scenario descritto da Check Point Research nella pubblicazione “BTR Reforged”, firmata dal ricercatore Jiří Vinopal: il driver BTR.sys (Boot Time Removal Tool), componente integrato di Defender e presente in ogni installazione Windows da Windows 7 fino a Windows 11 25H2, può essere estratto, installato manualmente ed eseguito in una finestra di avvio in cui opera con pieni privilegi kernel (Ring 0), prima che i servizi di sicurezza siano attivi.

Cos’è BTR.sys e perché esiste

BTR.sys non è un file a sé stante distribuito con l’installer: è incorporato come risorsa (BOOTTIMETOOL) dentro MpEngine.dll, il motore di scansione di Defender. Il suo scopo legittimo è rimuovere malware particolarmente persistente durante il boot, quando il filesystem è ancora scrivibile ma i processi in user-mode non sono ancora attivi: file bloccati, chiavi di registro danneggiate, artefatti lasciati da rootkit. Per fare questo ha bisogno, ed è progettato per avere, la capacità di cancellare file protetti, spostare oggetti in percorsi come System32\drivers ed eliminare o riscrivere chiavi di registro senza i normali controlli ACL.

Il punto debole individuato da Vinopal non è un bug di memoria o un buffer overflow, ma un problema architetturale di trust boundary: il protocollo di comunicazione con il driver è proprietario e non documentato, ma non è mai cambiato in modo sostanziale. Ogni pacchetto di configurazione inviato a BTR.sys è cifrato con RC4 usando una chiave a 256 byte hardcoded nel binario, rimasta identica per 18 versioni a 64 bit del driver. Una volta ricostruito il formato del protocollo, chiunque può parlare con BTR.sys come farebbe Defender stesso.

Come funziona l’attacco

Il proof-of-concept pubblico, denominato BTR_CLI, segue tre fasi:

• Estrazione: individua MpEngine.dll sul sistema e ne estrae il binario BTR.sys incorporato.
• Installazione “silenziosa”: registra il driver come servizio scrivendo direttamente nelle chiavi di registro sotto HKLM, bypassando completamente il Service Control Manager. Questo significa nessun log applicativo standard e, soprattutto, nessun Windows Event ID 7045 (“Service Installed”), l’evento su cui si basano molte regole SIEM per rilevare l’installazione di nuovi driver.
• Esecuzione nella “golden window”: durante la finestra di avvio in cui il filesystem è scrivibile ma Defender non ha ancora avviato i propri servizi di protezione, BTR.sys esegue in Ring 0 le operazioni richieste: cancellazione di file e directory bloccati (inclusi eseguibili di EDR e antivirus di terze parti), spostamento di file arbitrari in percorsi di sistema e manipolazione di chiavi di registro critiche.

Il requisito d’accesso non è banale ma nemmeno estremo: serve un account amministratore che possieda (o a cui venga assegnato, dato che BTR_CLI se ne occupa automaticamente per gli account già idonei) il privilegio SeLoadDriverPrivilege. È lo stesso privilegio necessario per caricare qualunque driver kernel, quindi in molti ambienti aziendali è più diffuso di quanto si pensi tra account di servizio e amministratori locali.

Perché non basta la blocklist

La differenza sostanziale rispetto ai classici attacchi BYOVD è che qui non si tratta di un driver di terze parti compromesso da revocare. BTR.sys è parte integrante di Defender: aggiungerlo alla Vulnerable Driver Blocklist o bloccarlo tramite WDAC significherebbe rompere una funzionalità legittima di Defender su tutte le macchine Windows. Microsoft Security Response Center, contattato da Check Point, ha confermato che la scoperta non soddisfa i criteri per una patch immediata, perché la tecnica presuppone privilegi amministrativi già ottenuti dall’attaccante — la classica linea di demarcazione “non è una vulnerabilità se serve già essere admin”. Il repository pubblico del proof-of-concept riporta inoltre l’indicazione “no patch is planned”, per quanto non si tratti di una dichiarazione ufficiale confermata pubblicamente da Microsoft.

Per un sistemista questo cambia l’approccio: non è un problema che si risolve con l’ennesimo aggiornamento, ma con il monitoraggio e con il controllo rigoroso di chi può caricare driver.

Come rilevare l’abuso in produzione

Check Point Research suggerisce alcuni indicatori concreti da integrare nelle regole di detection, in particolare su ambienti che usano Sysmon:

• Monitorare gli Alternate Data Stream (Sysmon Event ID 15) il cui nome termina con .sys:changelist, una firma tipica del comportamento di BTR.sys durante l’installazione.
• Correlare eventi di registro (Sysmon RegistryEvent, ID 12-13) relativi al gruppo di servizio “Boot Bus Extender” in assenza del corrispondente Event ID 7045: se il driver viene registrato in quel gruppo senza che il Service Control Manager risulti coinvolto, è un forte indicatore di installazione manuale.
• Osservare la creazione e cancellazione rapida del file \SystemRoot\Temp\BootClean.log da parte del processo System (PID 4): è l’artefatto lasciato dall’esecuzione del BTR durante il boot.

Queste regole non richiedono un nuovo prodotto: si possono implementare con la configurazione Sysmon esistente e instradarle verso il proprio SIEM (Sentinel, Splunk, Elastic) come regole di correlazione dedicate.

Mitigazione: il controllo primario resta l’accesso

Dato che non esiste una patch e la blocklist non è applicabile, la mitigazione più efficace, secondo i ricercatori, è restringere l’assegnazione del privilegio SeLoadDriverPrivilege tramite Group Policy, riducendolo ai soli account e gruppi che ne hanno realmente bisogno. In pratica:

• Verificare in Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment > Load and unload device drivers quali account e gruppi sono attualmente autorizzati.
• Rimuovere l’assegnazione implicita agli amministratori locali dove non strettamente necessaria, valutando l’uso di Privileged Access Workstation (PAW) per le operazioni che richiedono davvero il caricamento di driver.
• Applicare il principio dei privilegi minimi anche agli account di servizio, spesso dimenticati in questo tipo di audit.
• Integrare le regole Sysmon indicate sopra in un dashboard di detection dedicato, dato che la tecnica è pensata per non lasciare tracce negli event log standard.

Il caso BTR Reforged è un promemoria utile: man mano che gli attaccanti spostano l’attenzione dai driver di terze parti facilmente blocklistabili verso componenti “fidati per definizione” dei sistemi operativi, il perimetro difensivo si sposta sempre di più dal software alla gestione dei privilegi. Anche in assenza di una patch, un controllo rigoroso di chi può caricare driver e una detection basata su comportamento restano la difesa più solida disponibile oggi.

Fonte: Check Point Research, “BTR Reforged: Weaponizing Defender’s Remediation Driver as a Kernel Operation Primitive”, ripreso da 4sysops.

Microsoft Defender’s signed BTR.sys driver can erase security tools at boot – 4sysops

A Microsoft-signed driver built into Defender can be repurposed to remove antivirus and EDR components before they start, giving attackers with administrator-le

^{IT News (4sysops)}

(in)sicurezza digitale

2026-08-24 10:51:42

xpl0itrs colpisce il Gruppo Spaggiari: 6,1 TB rivendicati da 3.000 scuole italiane, l’azienda ridimensiona

Si parla di:
Toggle

Il 20 agosto 2026 il gruppo di cybercrime xpl0itrs ha rivendicato sul proprio leak site l’esfiltrazione di 6,1 terabyte di dati da oltre 3.000 istituti scolastici italiani, colpendo l’infrastruttura del Gruppo Spaggiari di Parma, storico fornitore del registro elettronico ClasseViva usato ogni giorno da milioni di studenti, famiglie e docenti in tutta Italia. La rivendicazione ha acceso i riflettori su uno dei fornitori più capillari dell’ecosistema scolastico nazionale, ma la risposta ufficiale dell’azienda — arrivata il giorno successivo — ridimensiona sensibilmente la portata dell’incidente, aprendo un caso di studio interessante sul divario tra ciò che i gruppi ransomware rivendicano e ciò che, effettivamente, è stato compromesso.

Il bersaglio: cent’anni di storia, 4.000 scuole, 4,5 milioni di utenti

Fondato nel 1926, il Gruppo Spaggiari si è evoluto da editore scolastico a fornitore di servizi digitali per la gestione della didattica, diventando negli anni uno dei nomi più riconoscibili della scuola italiana grazie a ClasseViva, il registro elettronico che connette istituti, insegnanti, studenti e famiglie. Secondo i dati riportati dall’azienda stessa, la piattaforma è oggi utilizzata da oltre 4.000 scuole attive con più di 4,5 milioni di utenti giornalieri — una superficie d’attacco enorme, che rende qualunque incidente di sicurezza su questo fornitore un potenziale problema di scala nazionale.

Chi è xpl0itrs: dalla supply chain agli attacchi ad alto profilo

xpl0itrs è un collettivo di cybercrime a scopo di lucro emerso all’inizio del 2026, che secondo le analisi di threat intelligence opera in stretto coordinamento con un altro gruppo, TeamPCP, condividendo accesso iniziale, strumenti e talvolta le stesse vittime all’interno di un ecosistema focalizzato sulla compromissione della supply chain software. Il modus operandi del gruppo si concentra su furto di token di sviluppo — Personal Access Token, credenziali OAuth, chiavi API — sottratti da ambienti di sviluppo, seguito da esfiltrazione di dati da repository e infrastrutture interne. Un membro che si fa chiamare “boxturtl” funge da portavoce pubblico, presentandosi come ex red teamer professionista.

Nelle scorse settimane il gruppo ha rivendicato, con diversi gradi di credibilità, violazioni ai danni di realtà molto note tra cui Spotify, il Dipartimento del Tesoro statunitense, OpenAI e Trustpilot, oltre a vittime indirette raggiunte tramite la compromissione di progetti open source come Trivy, BitWarden CLI, LiteLLM e Checkmarx KICS. Il profilo tracciato da Dataminr valuta le rivendicazioni del gruppo come “generalmente credibili”, basandosi su campioni di dati che contengono riferimenti plausibili a risorse di sviluppo interne e metadati Git coerenti con un accesso autentico mantenuto almeno fino a maggio 2026. Gli analisti segnalano inoltre legami indiretti con i cluster di estorsione DarkRomance e con il brand ShinyHunters, e una tecnica MITRE ATT&CK documentata — T1486, Data Encrypted for Impact — che colloca il gruppo nella categoria ransomware/extortion a tutti gli effetti, con almeno otto rivendicazioni pubblicate sul proprio leak site negli ultimi trenta giorni.

La rivendicazione contro la versione ufficiale

Secondo la rivendicazione pubblicata da xpl0itrs, i 6,1 TB sottratti includerebbero nomi, indirizzi email, numeri di telefono e almeno un campo password relativo a oltre 3.000 istituti scolastici — senza, secondo quanto dichiarato dagli stessi attaccanti, identificatori governativi come codici fiscali o numeri di documento. Spaggiari ha risposto con un comunicato ufficiale datato 21 agosto 2026, precisando che a essere compromesso sarebbe stato esclusivamente il componente “Modulistica Smart” della piattaforma Bergantini — uno strumento per la gestione della modulistica scolastica — e non il registro elettronico ClasseViva, i sistemi di gestione didattica o quelli amministrativi, definiti dall’azienda “un sistema distinto e separato” rispetto a quello colpito.

Un dettaglio significativo emerso dalla ricostruzione è la data dell’intrusione originaria: secondo Spaggiari l’accesso non autorizzato risalirebbe al 30 giugno 2026, quasi due mesi prima della rivendicazione pubblica del 20 agosto. Un intervallo così ampio tra compromissione e divulgazione è tutt’altro che insolito nel panorama ransomware: spesso corrisponde al tempo impiegato dagli attaccanti per l’esfiltrazione, l’eventuale negoziazione privata con la vittima (evidentemente naufragata, in questo caso) e, infine, la pubblicazione sul leak site come leva estorsiva. L’azienda ha dichiarato di aver notificato l’incidente al Garante per la protezione dei dati personali, all’Agenzia per la Cybersicurezza Nazionale (ACN) e alle forze dell’ordine.

Perché il divario tra le due versioni conta

Il contrasto tra la portata rivendicata (6,1 TB, oltre 3.000 scuole) e quella riconosciuta ufficialmente (un singolo modulo di modulistica) è un pattern ricorrente nelle dinamiche di doppia estorsione: i gruppi ransomware hanno tutto l’interesse a massimizzare la percezione del danno per aumentare la pressione sulla vittima e il valore di rivendita dei dati, mentre le aziende colpite tendono, comprensibilmente, a circoscrivere la narrazione pubblica il più possibile. Senza una verifica indipendente di un campione dei dati esfiltrati — al momento non disponibile pubblicamente — è prematuro stabilire quale delle due versioni sia più vicina alla realtà, ma il profilo di xpl0itrs, storicamente valutato come “generalmente credibile” dagli analisti, invita quantomeno alla cautela verso un ridimensionamento totale dell’incidente.

Rischi concreti per famiglie e istituti

Anche nello scenario più contenuto descritto da Spaggiari, l’esposizione di nominativi, email, numeri di telefono e credenziali legate al mondo scolastico costituisce un rischio concreto: questo tipo di dataset è particolarmente appetibile per campagne di phishing mirato verso segreterie scolastiche e famiglie (spesso mascherate da comunicazioni ClasseViva o da avvisi del Ministero dell’Istruzione), per tentativi di account takeover su servizi che riutilizzano le stesse credenziali, e per la profilazione di minori, un tema su cui il Garante privacy italiano è tradizionalmente molto attento. Le scuole coinvolte dovrebbero considerare, come misura precauzionale indipendentemente dall’entità confermata del breach, la rotazione delle credenziali di accesso al modulo Modulistica Smart, l’attivazione di autenticazione a più fattori dove disponibile e un’allerta mirata al personale su possibili tentativi di phishing a tema scolastico nelle prossime settimane.

Riferimenti e indicatori

# Incidente Gruppo Spaggiari / ClasseViva
Attore: xpl0itrs (coordinato con TeamPCP)
Tecnica MITRE ATT&CK: T1486 - Data Encrypted for Impact
Componente rivendicato come compromesso: Modulistica Smart (piattaforma Bergantini)
Data intrusione dichiarata da Spaggiari: 30 giugno 2026
Data rivendicazione pubblica: 20 agosto 2026
Data comunicato ufficiale Spaggiari: 21 agosto 2026
Volume dati rivendicato: ~6,1 TB / 3.000+ istituti scolastici
Tipologia dati rivendicati: nominativi, email, numeri di telefono, password (parziale)
Notifiche effettuate: Garante Privacy, ACN, forze dell'ordine

Fonti: comunicato ufficiale Gruppo Spaggiari, ransomware.live, Dataminr Intel Brief, GalaxyWarden, monitoraggio leak site.

(in)sicurezza digitale

2026-08-24 10:52:44

Manic: il trojan Android che ruba i PIN bancari e li fa uscire di casa via Bluetooth anche offline

Si parla di:
Toggle

Da febbraio 2026 un nuovo trojan bancario per Android circola con un obiettivo dichiarato: l’Ucraina. Ma “trojan bancario” è ormai una definizione troppo stretta per Manic, il malware descritto in un report di ThreatFabric come “un ibrido tra malware bancario e spyware”. Oltre a rubare PIN e credenziali finanziarie, Manic intercetta SMS, seed phrase di wallet crypto, cronologia chiamate e posizione GPS — e, quando il telefono infetto è offline, trova comunque il modo di far uscire i dati sfruttando altri dispositivi compromessi nelle vicinanze via Bluetooth e Wi-Fi Direct. È una capacità che ridefinisce cosa significhi davvero “isolare” un dispositivo compromesso.

Non una schermata di phishing, ma una tastiera che origlia

La maggior parte dei trojan bancari Android si affida a overlay che imitano l’interfaccia dell’app bersaglio per catturare le credenziali digitate dalla vittima. Manic fa qualcosa di più subdolo: grazie ai permessi di Accessibility Service, determina la posizione della tastiera digitale legittima dell’app e registra i singoli tocchi dell’utente senza alterare in alcun modo il funzionamento dell’app originale. Il risultato è che la vittima interagisce con la sua banca reale, sullo schermo reale, mentre in background il malware classifica ogni sequenza digitata — PIN di sblocco, seed phrase di wallet, codici OTP, password — semplicemente osservando dove e quando avvengono i tocchi.

A questa capacità si aggiungono sessioni di controllo remoto vere e proprie via WebRTC, con visualizzazione live dello schermo, mascherate dietro overlay neri o finte schermate di aggiornamento di sistema; la possibilità di sbloccare il dispositivo da remoto tramite la funzione autoEnterPin, una volta che il PIN è stato catturato; e comandi dedicati per disattivare Google Play Protect (disable_gp), così da ridurre le probabilità di essere rilevati anche dalle protezioni native di Android.

169 applicazioni monitorate, priorità all’Ucraina

ThreatFabric ha censito 169 identificatori di applicazioni nella lista bersagli di Manic: banche, exchange di criptovalute, app di pagamento P2P e “buy now pay later”, client email e browser. Il dato più significativo, però, è la composizione geografica dei target: il malware dà priorità esplicita a banche ucraine, servizi eID e piattaforme governative, oltre ad app di messaggistica sia commerciali sia a uso militare — una scelta che, nel contesto del conflitto in corso, suggerisce un interesse che va oltre la semplice frode finanziaria. La lista si estende poi a istituti finanziari in Russia, Polonia, Repubblica Ceca, Slovacchia, Austria, Germania, Francia, Spagna, Paesi Bassi, Estonia, Lituania e Regno Unito, con distribuzione tramite siti di phishing e dropper che si spacciano per utility di sistema o aggiornamenti di componenti Android/produttore (i nomi dei package individuati imitano deliberatamente Huawei, Honor, Lenovo, Motorola e persino Apple).

Lo sviluppo del malware appare tutt’altro che concluso. ThreatFabric ricostruisce una timeline chiara: la prima infrastruttura viene registrata a febbraio 2026, i servizi di produzione entrano in funzione tra marzo e aprile, la prima versione operativa di wrapper e implant compare a maggio, mentre a luglio arriva un aggiornamento che introduce protezioni anti-analisi rafforzate, caricamento del codice DEX direttamente in memoria (per complicare l’analisi statica) e un meccanismo di phishing per il “lock secret” del dispositivo.

Quando internet non basta: l’esfiltrazione mesh via Bluetooth

La caratteristica più originale di Manic — e quella che lo distingue nettamente dal panorama dei trojan Android — è il meccanismo di esfiltrazione dati progettato per funzionare anche quando il dispositivo infetto non ha accesso diretto a internet. I dati rubati vengono cifrati con AES-GCM e messi in una coda locale; il malware cerca poi altri dispositivi infetti nelle vicinanze tramite Wi-Fi Direct, Bluetooth RFCOMM o BLE GATT, costruendo percorsi “store-and-forward” multi-hop — fino a 4 salti per impostazione predefinita — capaci di far arrivare i dati a internet passando di device in device, finché uno di essi non trova connettività diretta. Se nessuna rotta è disponibile nell’immediato, i dati restano semplicemente in coda per essere ritrasmessi al primo tentativo utile.

Come sintetizzano gli stessi ricercatori di ThreatFabric, “rimuovere l’accesso diretto a internet da un dispositivo infetto non impedisce necessariamente l’esfiltrazione dei dati”. È una considerazione che dovrebbe far riflettere chi progetta contromisure basate solo su segmentazione di rete o blocco della connettività cellulare/Wi-Fi: in scenari con più dispositivi compromessi nello stesso ambiente — un ufficio, un’abitazione, persino un evento pubblico — la rete mesh creata dal malware stesso diventa il canale di comunicazione, aggirando completamente i controlli perimetrali tradizionali pensati per un singolo endpoint.

Due righe per i difensori

Per i team di sicurezza mobile e per gli istituti finanziari nei paesi target, Manic impone di ripensare due assunzioni comuni. La prima è che il monitoraggio comportamentale lato server (fraud detection basata su pattern di digitazione o velocità di interazione) rimane efficace anche quando l’attaccante non altera l’interfaccia dell’app: qui serve piuttosto rilevare l’uso anomalo di servizi di Accessibility da parte di app di terze parti non correlate al contesto bancario. La seconda è che l’isolamento di rete di un dispositivo sospetto non è più una garanzia sufficiente, quando l’esfiltrazione può avvenire tramite protocolli short-range verso dispositivi terzi già compromessi.

• Verificare quali app hanno richiesto e ottenuto permessi di Accessibility Service e Notification Listener, specie se provenienti da fonti fuori Google Play
• Monitorare pattern anomali di connessioni Wi-Fi Direct/Bluetooth in ambienti aziendali e finanziari sensibili
• Diffidare di dropper che si presentano come aggiornamenti di componenti di sistema legati a specifici produttori (Huawei, Honor, Lenovo, Motorola)
• Mantenere attivo Google Play Protect e verificare periodicamente lo stato di attivazione, dato che Manic include comandi dedicati per disattivarlo
• Per le banche: rafforzare l’autenticazione multi-fattore fuori-banda, poiché OTP e SMS risultano tra i dati intercettati con priorità

Indicatori di compromissione

[Wrapper - luglio 2026]
SHA-256: 80be0942d0e20b5006e240434f42512c8b3cd0d54eee858a25663c1a4224a576
Package: tech.intel.dialer.updater

[Implant - luglio 2026]
SHA-256: feea425cde1223fe7afdd7a1ea631678ec6282f6cc20c3d3c0fb97cdbcf65b9b
Package: org.lenovo.storage.processor

[Implant primario]
SHA-256: e7abc375f24d0dd2419e0bce4686c7301b3ee82ae38906c67d3481580f6c648e
Package: tech.apple.dialer.scheduler

[Wrapper - maggio 2026]
SHA-256: 2884108b35eba7b8099087405653c1b23c3839f0d5058c4d61341fc31cfc6040
Package: org.honor.secure.helper

[Implant - maggio 2026]
SHA-256: 2fb5b01ea5a483d60b659e85327a53c6661bdd630d4afd93dc5fe0941d3ccbbe
Package: dev.huawei.media.helper

[Implant correlato]
SHA-256: 7c12f1237090e32c18583f66f1a9e44b029ad7c1e61179e1d524fb3093abd59a
Package: io.motorola.secure.executor

[Comandi bot principali]
remote_control   - sessione schermo/webcam via WebRTC
get_logs         - esportazione log accessibility
export_sms       - esportazione SMS
export_calls     - esportazione cronologia chiamate
export_contacts  - esportazione contatti
export_file      - raccolta file locali
send_sms         - invio SMS dal dispositivo
ussd             - esecuzione codici USSD
geo              - attivazione geolocalizzazione
disable_gp       - disattivazione Google Play Protect

Fonte primaria: ThreatFabric Mobile Threat Intelligence. Report completo disponibile sul blog ufficiale di ThreatFabric.

Manic: Blend between Banking Malware & Spyware

Manic is a newly identified Android malware family with broad surveillance and remote-control capabilities, introducing an unusual Wi‑Fi mesh technique.

^{John Doe (ThreatFabric B.V.)}