Catasto Romania: come un ransomware è arrivato dagli accessi web agli hypervisor VMware dell’ANCPI

Primo: non è stato "cancellato" il catasto runeno.

Se avete seguito le notizie provenienti dalla Romania nel luglio 2026 avrete probabilmente letto la versione più semplice e spettacolare della storia, ovvero che qualcuno sarebbe entrato nei sistemi dello Stato ed avrebbe «cancellato il database catastale della Romania». Non è quello che emerge dall’analisi forense. A metà luglio i sistemi dell’ANCPI (Agenția Națională de Cadastru și Publicitate Imobiliară), l’agenzia rumena che gestisce catasto e pubblicità immobiliare, diventano indisponibili e fra i servizi colpiti finiscono e-Terra, ePayment, MyEterra, il Registro dei Proprietari, il Geoportal, RENNS ed altri sistemi utilizzati internamente e dai cittadini; il DNSC (Directoratul Național de Securitate Cibernetică) descrive l’impatto come esteso all’intera rete ANCPI, ma il database contenente i dati principali delle applicazioni era ospitato su Oracle Exadata e dalle evidenze raccolte, comprese le schermate pubblicate dall’attaccante, non emerge un accesso a quella base dati. Prima dello shutdown precauzionale gli amministrator verificarono inoltre che il database continuasse a rispondere correttamente alle interrogazioni ed esisteva una replica nel data center di Brașov aggiornata ogni quattro ore. Il database catastale centrale, quindi, è sopravvissuto; è stata pesantemente compromessa l’infrastruttura che permetteva di UTILIZZARLO, differenza enorme tecnicamente ma molto meno percepibile dall’utente, perché se il dato è integro mentre application server, autenticazione, macchine virtuali e servizi di rete sono a terra quel dato diventa comunque praticamente irraggiungibile. Ma L’attacco era iniziato giorni prima del ransomware. Il rapporto tecnico intermedio DNSC T66 del 22 luglio 2026, redatto dopo sette giorni di analisi, colloca il primo accesso ritenuto attendibile al 10 luglio alle 15:23:57 UTC, mentre la compromissione viene rilevata soltanto nei giorni successivi. Questo significa che l’attaccante ha avuto decine di ore per esplorare la rete, recuperare credenziali, aprire reverse shell, fare scansioni ed individuare percorsi verso sistemi progressivamente più privilegiati. Ed è già qui che il caso diventa interessante, perché il ransomware NON ARRIVA ALL’INIZIO ma alla fine: prima si prende un server, poi si cercano password, hash, token e chiavi, con quelle credenziali si entra altrove, da lì si raggiungono repository, directory service, monitoring e piattaforme di virtualizzazione e soltanto quando il controllo dell’infrastruttura è sufficiente ha senso premere il pulsante distruttivo. Quello che all’esterno appare come «infezione ransomware» è quindi l’ultima fase di un’intrusione molto più lunga.

La porta d’ingresso: OpenAM esposto su Internet

Secondo la ricostruzione DNSC il probabile initial foothold è openam.ancpi.ro, server Ubuntu con funzioni di autenticazione per ePayment e direttamente raggiungibile da Internet. Il rapporto associa il primo accesso allo sfruttamento di una vulnerabilità conosciuta nella componente OpenAM/ForgeRock ed indica esplicitamente CVE-2021-35464 / CVE-2024-36401. La prima attribuzione torna perfettamente: CVE-2021-35464 è una vulnerabilità critica di deserializzazione Java in ForgeRock AM/OpenAM, con CVSS 9.8, senza autenticazione richiesta e capace di portare a Remote Code Execution mediante una richiesta appositamente costruita; è pubblica dal 2021 ed è presente nel catalogo CISA delle vulnerabilità note come sfruttate attivamente. Se questa è stata davvero la falla utilizzata, nel luglio 2026 un servizio di autenticazione esposto direttamente ad Internet sarebbe rimasto vulnerabile ad una RCE conosciuta da circa cinque anni.

C'è qualche cosa che non torna, però, nella seconda CVE, ossia la CVE-2024-36401. Quello che non torna è che NON riguarda ForgeRock ma GeoServer/GeoTools ed è anch’essa una RCE pre-auth, derivante dalla valutazione insicura di espressioni XPath attraverso commons-jxpath (schema arcinoto). La questione è che poiché ANCPI utilizzava anche GeoServer non possiamo escludere che quella CVE compaia nel rapporto per una ragione collegata ad un’altra fase dell’incidente, ma nel punto in cui viene associata esplicitamente ad OpenAM/ForgeRock l’attribuzione appare, dal punto di vista tecnico, incongruente. Devo scriverlo perché sebbene il rapporto DNSC sia una fonte primaria (e resta la ricostruzione fondamentale dell’incidente) questo non significa che diventi automaticamente infallibile in ogni sua riga. Si passa poi dalla RCE alla web shell permanente, infatti dopo il primo accesso viene individuata una web shell JSP chiamata dec3.jsp, collocata sotto

/var/lib/tomcat/webapps/openam/

che permetteva di mantenere l’accesso al server ed impartire comandi successivi. È da notare che questo è il passaggio classico fra exploitation e persistence, in quanto ottenere Remote Code Execution significa poter eseguire qualcosa come ad esempio installare una web shell, insomma significa POTERCI TORNARE. A questo punto il server non è più soltanto vulnerabile ma diventa proprio LA testa di ponte all’interno della rete ANCPI, ed il vero obiettivo successivo non è nemmeno più trovare una nuova vulnerabilità (su ogni macchina) ma recuperare credenziali che consentano di attraversare sistemi diversi come utenti validi.

Il vero tesoro iniziale? Ovviamente....le credenziali

Attraverso OpenAM ed il relativo directory service OpenDJ/LDAP vengono raggiunti gli attributi userPassword relativi, secondo la stima DNSC, a circa due milioni di record, prevalentemente riconducibili ad utenti esterni. Questo introduce una precisazione importante rispetto alla comunicazione più rassicurante dei primi giorni: dire semplicemente che «nessun dato è stato compromesso» è troppo generico. Il rapporto non trova evidenze dell’accesso al database catastale Oracle Exadata, ma documenta comunque accessi ed acquisizioni di dati da altri sistemi, directory utenti comprese. In un’infrastruttura grande, una volta entrati, password, hash, token, chiavi e account amministrativi valgono spesso più di una nuova RCE perché permettono di presentarsi al sistema successivo non come aggressori ma come identità formalmente autorizzate.

Cade IBM WebSphere attraverso JMX/RMI

La progressione laterale continua su un server IBM WebSphere Application Server dove l’attaccante individua un servizio Java RMI ed un endpoint JMX/RMI raggiungibili internamente, sfruttando poi la relativa superficie di management con Metasploit fino ad ottenere esecuzione di codice ed una sessione Meterpreter sotto l’account di servizio ibm. È uno dei passaggi che spiegano bene la differenza fra sicurezza perimetrale e sicurezza interna: un amministratore può pensare che JMX non sia esposto su Internet e quindi sia relativamente sicuro, ma questo ragionamento funziona soltanto finché nessuna macchina interna viene compromessa. Quando l’aggressore possiede già una shell nella rete, tutto ciò che è «sicuro perché accessibile soltanto internamente» entra improvvisamente nella superficie d’attacco.

Anche GitLab era rimasto fermo al 2021

Il 12 luglio viene compromessa anche l’istanza GitLab interna. Il rapporto DNSC documenta l’uso del modulo Metasploit exploit/multi/http/gitlab_exif_rce, che sfrutta CVE-2021-22205, la nota Remote Code Execution legata alla componente ExifTool delle vecchie versioni GitLab, permettendo di ottenere una reverse shell con l’account di servizio git. Di nuovo, una vulnerabilità del 2021 utilizzata nel 2026. Dalla base gitlabhq_production vengono quindi estratti account ed hash delle password e l’attaccante comincia a lavorare offline su quegli hash; almeno una password recuperata mediante cracking risulta poi valida anche contro il realm Kerberos dell’organizzazione. Ed è questo il momento in cui un problema locale diventa sistemico: PASSWORD REUSE. Una credenziale rubata su GitLab funziona su un altro sistema e la catena smette progressivamente di essere una sequenza di exploit per diventare un furto di identità amministrative.

L’accesso a GitLab porta inoltre con sé un danno che sopravvive al disaster recovery, perché l’attaccante può raggiungere repository relativi ai sistemi proprietari ANCPI, compresi componenti di e-Terra ed altre applicazioni interne. Un server si reinstalla ed una password si cambia, ma il codice sorgente sottratto può essere studiato offline per settimane alla ricerca di endpoint dimenticati, errori logici, API interne oppure hardcoded secrets; la superficie di rischio quindi non torna automaticamente a zero nel momento in cui il servizio viene rimesso online.

Zabbix diventa uno strumento dell’attaccante

Anche la piattaforma di monitoring Zabbix entra nella catena di compromissione. Una volta ottenuto accesso amministrativo, l’attaccante utilizza una funzione legittima della piattaforma, gli script eseguibili dal server centrale, per lanciare scansioni ed aprire una reverse shell verso un host già sotto il proprio controllo. È un esempio quasi scolastico di Living off the Land: non occorre installare malware dappertutto quando posso usare SSH, sistemi di monitoring, API amministrative, shell Linux ed altri strumenti già presenti nell’infrastruttura. Sono strumenti perfettamente legittimi, è il contesto nel quale vengono usati a renderli ostili.

Poi viene compromesso perfino il SIEM

Uno dei passaggi più paradossali riguarda FortiSIEM 7.2, cioè proprio uno degli strumenti che teoricamente avrebbero dovuto aiutare a vedere l’attaccante. Il personale ANCPI riferisce agli investigatori che quella soluzione era stata inserita essenzialmente come POC (Proof of Concept) e non disponeva di una raccolta log sufficiente per ricostruire l’incidente, ma nel database phoenixdb erano conservate credenziali di numerosi apparati di rete. Le password risultavano protette con un meccanismo AES reversibile e, una volta raggiunto il credential store, potevano quindi essere recuperate; il rapporto segnala inoltre il riutilizzo delle stesse credenziali su apparati Juniper collocati in segmenti e località differenti. Il sistema di monitoring si trasforma così in una specie di rubrica centralizzata delle chiavi necessarie per attraversare la rete, ed è difficile trovare un esempio più efficace del motivo per cui un credential store deve essere trattato come un asset di criticità estrema.

Il punto di non ritorno è vCenter

Fino a questo momento l’attaccante possiede diversi sistemi, poi raggiunge VMware vCenter ed è qui che cambia completamente la scala dell’incidente. Il DNSC individua un login proveniente dall’ambiente ePayment compromesso verso il vCenter utilizzando l’account administrator@ancpi.ro, evento definito anomalo proprio perché una VM appartenente al segmento di produzione stava iniziando sessioni direttamente verso il management plane della virtualizzazione. Una application VM compromessa NON dovrebbe poter parlare liberamente con il sistema che controlla gli hypervisor; il piano di management dovrebbe vivere in una rete separata, dietro jump host o PAM, ACL esplicite, MFA e workstation amministrative dedicate. Qui invece dall’application tier si è riusciti ad arrivare alla centrale di comando della virtualizzazione.

Come se non bastasse, il server utilizzava VMware vCenter Server 6.0.0 build 5112529, versione che il DNSC identifica espressamente come obsoleta ed uscita dal supporto. Broadcom/VMware indica infatti il 12 marzo 2020 come End of General Support di vSphere 6.0, quindi nel luglio 2026 il cuore dell’infrastruttura virtuale ANCPI era amministrato attraverso una generazione il cui supporto generale era terminato più di sei anni prima. Non significa automaticamente che l’accesso sia avvenuto sfruttando una specifica falla di vCenter, perché nel percorso documentato entrano anche credenziali valide, ma significa che il management plane più importante dell’infrastruttura era basato su software molto oltre il proprio ciclo di supporto.

Una volta preso vCenter, 1.083 server diventano un inventario

Dal database PostgreSQL di vCenter l’attaccante esegue query e comandi per enumerare l’infrastruttura virtuale, ricavando un inventario di 1.083 VM con hostname, indirizzi IP ed host ESXi di appartenenza. È quasi il sogno di qualunque aggressore: non devo più scoprire la rete perché il sistema amministrativo ME LA DESCRIVE. Il rapporto mostra anche l’uso di strumenti VMware, query vSphere, browsing dei datastore ed accesso al Managed Object Browser per navigare direttamente fra gli oggetti della virtualizzazione. A questo punto il problema non è più «hanno bucato un sito», hanno raggiunto IL PIANO DI CONTROLLO DEL DATA CENTER.

Il Domain Controller copiato come un normale file

Fra le evidenze più pesanti compare un comando scp utilizzato per iniziare il trasferimento del disco virtuale dc1-flat.vmdk, appartenente ad un Domain Controller Active Directory, verso un server controllato dall’attaccante. È un passaggio estremamente serio perché una volta ottenuto il VMDK di un Domain Controller non devo necessariamente continuare ad attaccarlo online, posso analizzare il disco offline cercando database AD, registry hive, configurazioni e materiale utile all’estrazione delle credenziali. Il DNSC mantiene però correttamente una distinzione fondamentale: la copia è documentata, mentre non esiste prova che l’intera esfiltrazione prevista e la successiva estrazione di tutti i segreti Active Directory siano state completate.

Nella stessa attività post-compromissione compare anche BloodHound, strumento diffusissimo nei penetration test e altrettanto utile agli attaccanti per modellare relazioni fra utenti, gruppi, computer e privilegi Active Directory; il rapporto documenta l’enumerazione dei membri dei Domain Admins e di percorsi di controllo particolarmente estesi. Anche qui non servono armi segrete da intelligence: servono accesso, tempo ed un’infrastruttura che permetta di continuare a passare da un livello di fiducia all’altro.

Solo adesso arriva ByteToCrypt

Ed arriviamo finalmente al ransomware. Il DNSC trova l’eseguibile ByteToCrypt con SHA-256 14ed580291658fa6410f4cbb18d9a2f979b93f4ce640c7445d999bcf440492e8 sugli host ESXi dc-r104-h05, dc-r104-h03, dc-r104-h02 e dc-r103-h03, dentro /tmp/; il binario viene eseguito e comincia a cifrare i file raggiungibili dagli hypervisor. Ma anche qui occorre correggere una semplificazione: una reverse engineering indipendente del sample pubblicata da TLPBLACK mostra che ByteToCrypt non è propriamente un ransomware progettato per VMware ESXi, è un encryptor Linux relativamente generico che percorre ricorsivamente la directory corrente. Non possiede una sofisticata logica interna per enumerare vSphere, fermare VM oppure comprendere i datastore; è l’attaccante ad averlo portato NEL PUNTO GIUSTO e ad avergli dato accesso ai file giusti. Per il malware un VMDK è semplicemente un file.

L’analisi TLPBLACK descrive ByteToCrypt come un ELF64 Linux compilato su Alpine, staticamente collegato anche ad OpenSSL e con una logica ransomware relativamente piccola. Il codice presenta diverse fragilità operative, fra gestione incompleta degli errori I/O, path a dimensione fissa, perdita di metadata e possibilità di dichiarare completate operazioni che in realtà hanno fallito; usa però per ogni file una chiave AES-256 ed un IV casuali, proteggendo la chiave tramite RSA-4096 OAEP. E qui c’è la lezione: UN RANSOMWARE SCRITTO MALE NON È NECESSARIAMENTE UN RANSOMWARE DECIFRABILE. Gli analisti non hanno trovato una scorciatoia crittografica capace di ricostruire le chiavi, ed il DNSC dichiarava di non possedere un decryptor e di non averne individuato uno in fonti aperte.

Dopo la cifratura ByteToCrypt esegue inoltre nove comandi anti-forensics che tentano, fra le altre cose, di fermare servizi di logging, disabilitare audit, pulire il kernel ring buffer, cancellare log, svuotare history della shell e rimuovere known_hosts. Alcuni comandi non hanno senso oppure non funzionano su ESXi, altro indizio del fatto che il malware non sia stato realmente costruito attorno alla piattaforma VMware, ma sono comunque sufficienti a rendere ancora più complessa una ricostruzione forense già penalizzata da una visibilità molto scarsa.

Circa cento VM vengono cancellate

ANCPI inizialmente riteneva di avere circa 700 macchine virtuali e che un centinaio fossero state eliminate, mentre l’analisi successiva dell’inventario vCenter porta il totale a 1.083 mantenendo approssimativamente a cento il numero di VM cancellate. In termini aritmetici parliamo di circa il nove per cento delle macchine, ma la percentuale dice poco: se fra quelle cancellate ci sono sistemi di autenticazione, application server e componenti infrastrutturali non serve distruggere il cento per cento dei server per ottenere un outage quasi totale. Un attacco informatico non deve togliere ogni vite al motore, gli basta togliere quelle che LO TENGONO INSIEME.

Anche i backup Veeam finiscono nella catena

Il rapporto documenta inoltre la cancellazione di più backup raggiungibili, compresi quelli relativi a GitLab, contabilità, GeoServer e copie di Domain Controller; gli amministratori ANCPI sostengono però che si trattasse prevalentemente di backup delle VM predisposte per test e non delle macchine di produzione. La parte più importante dell’infrastruttura dati aveva invece un’altra strategia: Oracle Exadata era replicato ogni quattro ore nel data center di Brașov. È probabilmente una delle ragioni per cui oggi raccontiamo un lungo fermo del catasto e non la perdita irreversibile dei dati catastali centrali.

Il dettaglio incredibile: sette minuti di log

Se dovessi scegliere il singolo dettaglio più incredibile dell’intera vicenda probabilmente sceglierei questo: il WAF (Web Application Firewall) davanti all’applicazione ePayment conservava appena SETTE MINUTI di log. Non sette giorni e nemmeno sette ore, sette minuti. Il DNSC lo dichiara esplicitamente ed osserva che una retention simile ha limitato drasticamente la possibilità di ricostruire a posteriori il traffico diretto all’applicazione compromessa. Una parte dell’indagine ha quindi dovuto utilizzare non soltanto gli artefatti rimasti sui sistemi e la command history ma perfino gli screenshot pubblicati dallo stesso aggressore. È un ribaltamento quasi surreale: l’attaccante aveva documentato alcune proprie attività meglio di quanto l’infrastruttura della vittima fosse stata capace di registrarle.

E l’antivirus era soltanto sui PC

Il rapporto rileva la presenza di Bitdefender ma specifica che risultava installato soltanto sulle workstation dei dipendenti, non sui server analizzati. Precisiamon che in questo contesto un antivirus da solo non avrebbe impedito l'incidente, ma in una infrastruttura moderna server--> application server --> sistemi di management --> endpoint amministrativi devono fornire telemetria EDR/XDR o capacità equivalenti, altrimenti di ciò che sta capitando nessuno viene allertato. Un processo anomalo che scarica tool, apre reverse shell, esegue scansioni, copia enormi VMDK oppure lancia un encryptor sugli hypervisor dovrebbe produrre più di qualche campanello d’allarme.

Quindi qual è stata la falla?

La realtà dimostra che NON ESISTE UNA SOLA FALLA, ed è proprio questo il punto più interessante dell’incidente ANCPI, perchè La vulnerabilità iniziale è soltanto la prima tessera del domino, ma poi arrivano burst di falle. Applicazioni Internet-facing non aggiornate, almeno una RCE nota dal 2021, GitLab vulnerabile ad un’altra RCE del 2021, servizi amministrativi interni sfruttabili dopo il foothold, software di virtualizzazione fuori supporto da oltre sei anni, password riutilizzate fra sistemi differenti, credenziali amministrative memorizzate in forma reversibile, segmentazione insufficiente fra application tier e management plane, accesso a vCenter da una VM di produzione, SIEM poco utile alla detection, WAF con sette minuti di retention, protezione endpoint concentrata sulle workstation, backup raggiungibili dall’infrastruttura compromessa ed una separazione insufficiente fra identità, monitoring, applicazioni ed amministrazione. Interessante no? Analizziamo la (noiosa ma rivelatrice) catena dei se (IF-CHAIN) : se OpenAM fosse stato compromesso ma correttamente isolato avremmo probabilmente parlato della compromissione di OpenAM; se GitLab fosse stato compromesso ma le password non fossero state riutilizzate avremmo parlato di GitLab; se la VM ePayment non avesse potuto comunicare con la rete di management VMware avremmo avuto un’altra barriera, se vCenter fosse stato separato dietro jump host, MFA ed ACL specifiche un’altra ancora, se i backup fossero stati completamente immutabili e non raggiungibili dagli account amministrativi ordinari un’altra ancora. Non mi stancherò mai di dire che la sicurezza non consiste nella speranza che nessuna barriera venga mai superata, ma consiste nel fare in modo che SUPERARNE UNA NON FACCIA CADERE AUTOMATICAMENTE TUTTE LE ALTRE! Oltretutto non servivano nemmeno zero-day, né cyber-armi da intelligence e nemmeno essere un genio dell'hacking, e lo vediamo in un altro aspetto. molto istruttivo del tooling. Nella chain compare una mappazza davvero difficile da digerire: Metasploit, shell Linux, nmap, SSH, BloodHound, credential cracking, query PostgreSQL, strumenti VMware, SCP, web shell e software amministrativo già presente nell’infrastruttura; il DNSC mappa infatti una lunga parte delle attività dentro MITRE ATT&CK, dall’Exploit Public-Facing Application all’uso di Valid Accounts, Network Service Scanning, Remote Services, Credential Dumping, Exfiltration, Data Encrypted for Impact ed Inhibit System Recovery. Quindi direi che non emerge la necessità di immaginare qualche fantomatica arma informatica segreta, la sofisticazione sta soprattutto nel concatenare correttamente errori assolutamente ordinari. E la regola è sempre quella: una singola vulnerabilità critica può non diventare catastrofica ma DIECI VULNERABILITÀ CONCATENATE NELL’ORDINE GIUSTO POSSONO DIVENTARLO.

Il ransomware è stato l’effetto, non la causa

He sì, assolutamente. ByteToCrypt ha cifrato i file, ma ByteToCrypt non ha creato la mancanza di segmentazione, non ha deciso di mantenere vCenter 6.0 nel 2026, non ha impostato sette minuti di retention sul WAF, non ha riutilizzato password fra GitLab, Kerberos ed altri servizi, non ha deciso dove conservare le credenziali degli apparati e non ha lasciato componenti del 2021 senza patch. Il malware entra in scena quando quasi tutto il lavoro importante è già stato fatto. Per questo definire l’incidente semplicemente come «attacco ransomware» rischia persino di nasconderne la vera natura: prima di tutto è stato un fallimento di DIFESA IN PROFONDITÀ.

Il catasto è tornato perché il dato centrale non era morto

e-Terra è tornato progressivamente operativo dall’11 agosto 2026 e nei giorni successivi ANCPI ha dovuto assorbire un arretrato enorme: fra l’11 ed il 19 agosto risultavano registrate 329.476 richieste, delle quali 279.242 già lavorate. Quasi un mese di indisponibilità per un’infrastruttura centrale dello Stato resta un incidente gravissimo, ma esiste una differenza sostanziale fra ricostruire l’application layer attorno a dati ancora integri e dover ricostruire dati immobiliari che non esistono più. La replica geografica di Oracle Exadata ha quindi svolto un ruolo fondamentale, ed il paradosso finale è che la parte apparentemente più preziosa del sistema, il database catastale, era anche quella più separata e ridondata: È TUTTO CIÒ CHE GLI STAVA ATTORNO AD ESSERE CROLLATO.

Qual'è la lezione?

La lezione non riguarda soltanto la Romania e nemmeno il catasto, riguarda qualsiasi infrastruttura costruita negli anni aggiungendo server, middleware, sistemi legacy, monitoring, repository, hypervisor, appliance e chi più ne ha più ne metta (IT COMPULSIVO docet) senza mantenere con lo stesso rigore la separazione fra i rispettivi livelli di fiducia. Il vero disastro non è che un server OpenAM vulnerabile possa essere compromesso, perché prima o poi un server verrà compromesso; il disastro comincia quando da quel server posso raggiungere il successivo, dal successivo recuperare una password, usare quella password altrove, trovare il SIEM, recuperare altre credenziali, attraversare una VM applicativa per raggiungere vCenter, vedere da vCenter tutti gli hypervisor e dagli hypervisor tutti i dischi. A quel punto l’attaccante non sta più forzando una porta dopo l’altra, GLI ABBIAMO CONSEGNATO IL MAZZO DI CHIAVI DELL’EDIFICIO, usando la compromissione iniziale per arrivare e controllare il management plane e trasformando infine quel controllo nella cifratura e nella cancellazione di una parte dell’infrastruttura!