ransomware

Attacco hacker alla Sapienza: servizi bloccati, ma al momento non c’è rivendicazione



Indirizzo copiato

Sistemi digitali universitari bloccati a seguito di un attacco informatico che ha colpito la Sapienza di Roma e impattante su macchine di produzione. Ecco cosa sappiamo sull’incidente in fase di risoluzione

Pubblicato il 3 feb 2026

Dario Fadda

Research Infosec, fondatore Insicurezzadigitale.com



Attacco hacker alla Sapienza

All’università “La Sapienza” di Roma l’attacco informatico è arrivato nel momento peggiore possibile: fine sessione invernale, ultimi appelli, Infostud saturo di accessi e un’intera comunità accademica che vive ormai quasi tutto, dagli esami ai pagamenti, attraverso un’unica superficie digitale.

Dalla mattina del 02 febbraio il sito istituzionale è irraggiungibile e i servizi online dell’ateneo sono bloccati; i primi segnali si sono visti già nella serata precedente, quando l’accesso a Infostud – il portale che gestisce prenotazioni esami, carriere, pagamenti e pratiche amministrative – ha iniziato a restituire errori agli studenti che tentavano di entrare nel sistema.

Cosa è successo all’Università La Sapienza di Roma

La conferma ufficiale è arrivata a ridosso della tarda mattinata, con un messaggio dell’ateneo: c’è stato un attacco informatico, è stato disposto “l’immediato blocco dei sistemi di rete” e una task force tecnica è al lavoro per la bonifica e il ripristino graduale dell’infrastruttura, facendo leva su backup che, almeno secondo quanto comunicato, non sarebbero stati intaccati.

La dinamica, per come viene raccontata nelle prime note ufficiali e nei comunicati circolati nelle redazioni stampa, è quella classica di un incidente che si scopre mentre è già in corso la fase più impattante.

L’evento è stato abbastanza grave da spingere l’ateneo a isolare in blocco la rete, disconnettendo sistemi interni e front-end pubblici per ridurre la superficie d’attacco e impedire ulteriori movimenti laterali, a scapito però di qualsiasi continuità operativa.

Attacco hacker alla Sapienza: potrebbe trattarsi di un ransomware

Alcune fonti parlano esplicitamente di un ransomware che avrebbe “coinvolto tutta la rete IT” dell’università, costringendo a un blackout generalizzato dei servizi informatici, dagli applicativi amministrativi ai portali per studenti e personale.

Non è un dettaglio di poco conto: se il ransomware è riuscito a propagarsi a livello di dominio o di segmenti critici della rete, significa che l’attore ha avuto il tempo di spostarsi, enumerare asset, probabilmente raggiungere file server condivisi e sistemi core, prima che le misure di contenimento entrassero davvero in azione.

Al momento della stesura di questo articolo, non ci sono rivendicazioni criminali pubblicate (fonte: Ransomfeed).

La comunicazione ufficiale

Il comunicato del prorettore alle Tecnologie digitali e alla Cybersecurity, Leonardo Querzoni, è scritto nel linguaggio tipico degli incidenti gravi: tutti i sistemi temporaneamente bloccati “per garantire la sicurezza e l’integrità dei dati”, infrastruttura informatica “vittima di un attacco informatico”, supporto immediato dell’Agenzia per la Cybersicurezza Nazionale per l’analisi e il ripristino dei servizi critici.

Dietro queste formule si intravede una sequenza già nota a chi si occupa di incident response in ambienti complessi: rilevazione di attività anomale sui server o sugli endpoint, escalation al team interno, valutazione sommaria dell’estensione, attivazione del piano di risposta e, a quel punto, la scelta (politica, oltre che tecnica) di tirare il cavo e mettere offline tutto quello che è possibile scollegare.

L’uso esplicito del termine “bonifica” lascia intendere che non si parla soltanto di rollback o di failover verso sistemi di backup, ma di un processo più ampio di eradicazione della minaccia, che potrebbe includere reinstallation bare-metal, rotazione di credenziali privilegiati, hardening accelerato di segmenti di rete finora troppo aperti.

La superficie d’attacco di un ateneo come La Sapienza, il più grande in Italia e uno dei più grandi d’Europa, è intrinsecamente ampia: migliaia di endpoint, sistemi legacy stratificati nel tempo, applicativi custom nati in dipartimenti diversi, identity store spesso eterogenei, oltre a un mix di on-premise, virtualizzazione storica e servizi cloud.

Un ransomware che riesca ad attraversare questa complessità non è quasi mai il risultato di un singolo errore, ma di una catena di condizioni favorevoli: credenziali riutilizzate o sottratte attraverso phishing, vulnerabilità su servizi esposti in rete, VPN o accessi remoti non correttamente segmentati, patch management incompleto su server che non possono “permettersi” downtime.

La narrativa ancora prudente sull’origine dell’attacco – si parla di “ipotesi ransomware” e non di rivendicazioni o famiglie specifiche – suggerisce che in questo momento i team siano concentrati su triage e containment, mentre la threat intelligence lavora in background per capire se la firma, gli artefatti o l’infrastruttura di comando e controllo corrispondano a qualche gruppo già noto nel panorama che negli ultimi mesi ha preso di mira enti pubblici e PA italiane.

Le ipotesi tecniche dietro l’attacco

C’è poi la questione, tecnicamente cruciale, dei backup. Nella comunicazione ufficiale viene specificato che i sistemi di backup “non sono stati interessati dall’incidente”, formula che, letta con l’occhio di chi ha visto altri casi simili, è sia rassicurante sia un indizio importante sull’architettura.

Se è vero, significa che almeno una parte delle copie di sicurezza è effettivamente offline o logicamente separata dal dominio compromesso, non raggiungibile con gli stessi privilegi che l’attore ha sfruttato per cifrare o bloccare i sistemi operativi.

Per un ransomware moderno questo è un ostacolo non banale, perché le prime fasi dell’attacco puntano proprio a disabilitare o compromettere i backup, ripulendo snapshot e volumi, per massimizzare la leva estorsiva.

D’altro canto, anche con backup intatti, il ripristino di un ecosistema universitario di queste dimensioni non è una questione di ore, ma di giorni o settimane, soprattutto se si decide di non fidarsi di nessuna immagine preesistente e di ricostruire tassello per tassello riducendo al minimo il rischio di reinfezione.

Infostud, in questo quadro, è il simbolo perfetto della dipendenza da quello che in gergo si chiama “un singolo punto di fallimento”. È un portale che integra autenticazione, gestione delle carriere, iscrizioni, scadenze economiche, logiche di prenotazione legate a calendari d’aula e disponibilità docenti, e che negli anni si è trasformato nell’interfaccia principale tra l’università e i suoi studenti.

Nel momento in cui il sistema va giù – o viene tenuto giù deliberatamente per motivi di sicurezza – intere routine si inceppano: appelli pieni che non si possono confermare, pagamenti che non si possono registrare, scadenze per lauree e tirocini che diventano improvvisamente incerte.

Sui social, dove gli studenti hanno iniziato a riversare frustrazione e sarcasmo, si leggono messaggi che parlano di “Infostud di nuovo sotto attacco hacker” e di accesso al “database della segreteria”, con il timore molto concreto che l’incidente non sia solo disponibilità, ma anche confidenzialità dei dati: esami, carriere, informazioni personali, tutta quella materia prima che in ambito universitario rappresenta il vero long tail dell’impatto.

Le ipotesi sul punto di accesso iniziale dell’attacco

Dal punto di vista strettamente tecnico, quello che sappiamo oggi permette già di intuire alcuni vettori possibili, pur senza la pretesa di ricostruire l’incidente.

In un’università è plausibile immaginare un primo foothold su un endpoint di un dipendente o di uno studente con privilegi locali, magari compromesso via phishing con allegati malevoli o link a loader che sfruttano macro, script o vulnerabilità del browser.

Una volta ottenuto un accesso iniziale, i gruppi ransomware spesso si muovono con strumenti “legittimi”: PowerShell, PsExec, RDP, gestione remota integrata, sfruttando l’infrastruttura stessa come vettore e cercando credenziali di dominio memorizzate, token, chiavi API.

In un contesto con segmentazione debole, VLAN che comunicano troppo liberamente e controlli laterali limitati, l’attaccante può muoversi verso i server che ospitano database e applicativi core, cifrando file system, corrompendo configurazioni o disabilitando servizi per massimizzare il down.

La scelta dell’ateneo di isolare la rete a livello macro indica che la propagazione reale o potenziale è stata giudicata abbastanza grave da rendere rischioso qualsiasi tentativo di mantenere in vita anche solo segmenti “puliti” in produzione.

Le università e l’istruzione nel mirino criminale

L’ombra che torna a proiettarsi è quella del precedente del 2011, quando La Sapienza fu tra i tanti atenei coinvolti in un attacco su scala internazionale che interessò università da Bari a Cagliari, da Napoli a Milano, con compromissioni di database contenenti dati sensibili, password, recapiti e codici fiscali.

Quell’episodio apparteneva a un’epoca in cui il movente era più spesso legato alla dimostrazione di capacità e alla sottrazione di dati, mentre oggi il ransomware aggiunge una dimensione estorsiva industrializzata, fatta di doppia e tripla esfiltrazione, data leak site, countdown pubblici e pressione mirata su vittime percepite come “obbligate” a pagare per ripartire.

Se si confermerà che anche questa volta l’obiettivo è stato bloccare servizi per chiedere un riscatto, sarà interessante capire se l’università abbia adottato policy esplicite sul non pagamento e se queste policy siano state testate in tabletop exercise che includono scenari di completa indisponibilità dei sistemi in piena sessione esami.

Report recenti stimano che gli attacchi ransomware verso il settore education siano cresciuti in maniera significativa negli ultimi cicli, con incrementi ben oltre il 50% anno su anno, e con costi che vanno ben oltre il riscatto richiesto: giorni di lezioni perse, interruzione di attività di ricerca, migrazioni forzate di piattaforme didattiche, oltre all’impatto reputazionale con studenti e famiglie.

L’Italia, che secondo dati ACN ha visto un +53% di attacchi cyber nel solo primo semestre 2025, con PA e sanità in prima linea, porta ora in vetrina uno dei suoi atenei simbolo come vittima di un incidente che rende plastico quanto la trasformazione digitale, senza un investimento proporzionato in security, produca infrastrutture fragili esposte a una minaccia ormai quotidiana.

La presenza in campo dell’Agenzia per la Cybersicurezza Nazionale è un altro elemento tecnico-politico da non sottovalutare: significa coordinamento con CERT, protocolli di segnalazione verso altre strutture pubbliche, possibilità di correlare indicatori dell’attacco con campagne viste su altri target nazionali, e un percorso di gestione che non si limita alla rimessa in piedi dei server ma include valutazioni legali, di notifica verso gli interessati e, se necessario, di interazione con forze dell’ordine e Autorità garante privacy.

In questo scenario, la scelta delle parole nelle comunicazioni pubbliche diventa parte integrante della risposta all’incidente: ammettere subito l’attacco, rassicurare sui backup, sottolineare il coinvolgimento di ACN, ma sospendere ogni commento su eventuali esfiltrazioni o richieste di riscatto finché le evidenze forensi non sono solide.

Che insegnamento ci lascia l’attacco a La Sapiena

Una lezione che il caso de La Sapienza ci sottolinea è la dimostrazione che i piani di incident response non possono restare nel cassetto, che i backup scollegati non sono una mania da paranoici, che network segmentation, privilegi minimi e continuous monitoring non sono parole chiave da slide ma differenza concreta tra un disservizio limitato e un blackout totale.

È anche il momento per il sistema universitario italiano di chiedersi se voglia continuare a ragionare per singolo ateneo o se non sia il caso di spingere verso architetture condivise, SOC federati, linee guida vincolanti e investimenti coordinati in sicurezza, trattando i campus non più come isole un po’ bohémien della rete, ma come quello che sono diventati da tempo: datacenter complessi, ad alta esposizione, pieni di dati preziosi e quindi bersagli privilegiati.

Nel frattempo, a Roma, la priorità resta una: riaccendere i sistemi senza riportare dentro il fuoco. E farlo in fretta, in un contesto in cui ogni ora offline non è solo una riga in un report di disponibilità, ma può avere effetti su una laurea rinviata, un esame mancato, un pezzo di fiducia in meno nella capacità delle istituzioni di proteggere le proprie infrastrutture digitali.

guest

0 Commenti
Più recenti
Più votati
Inline Feedback
Vedi tutti i commenti

Articoli correlati

0
Lascia un commento, la tua opinione conta.x