Raportul tehnic al DNSC descrie una dintre cele mai grave breșe din administrația publică românească. Dincolo de mecanica atacului, documentul ridică o întrebare incomodă: în ce stare se află, de fapt, IT-ul instituțiilor statului și cine răspunde pentru el.
Sistemele Agenției Naționale de Cadastru și Publicitate Imobiliară (ANCPI) au fost paralizate în noaptea de 13 spre 14 iulie 2026 de un atac de tip ransomware cu dublă extorcare, atribuit de investigatori grupării de criminalitate informatică ByteToBreach. Timp de mai multe zile au fost indisponibile platforma e-Terra, sistemul de plăți online și portalurile publice ale instituției, blocând activitatea notarilor, a băncilor, a experților cadastrali și a cetățenilor care aveau nevoie de operațiuni asupra proprietăților. Directoratul Național de Securitate Cibernetică (DNSC), sesizat pe 14 iulie, a publicat pe 22 iulie o analiză tehnică intermediară, neclasificată, care reconstituie modul în care a fost compromisă infrastructura.
Concluzia raportului este directă: atacul putea fi prevenit. Directorul DNSC, Dan Cîmpean, a explicat public că atacatorii au folosit vulnerabilități cunoscute, unele semnalate de directorat cu puțin timp înainte. Tot el a numit atacatorul „norocos” și a spus că „i s-au aliniat planetele”. Cele 28 de pagini ale documentului arată de ce.
Ce s-a întâmplat, potrivit raportului
Potrivit DNSC, punctul de acces inițial nu a fost, așa cum a lăsat să se înțeleagă narațiunea publică din primele zile, o simplă „parolă slabă”. A fost o vulnerabilitate cunoscută din 2021 într-o componentă de autentificare expusă în internet, OpenAM/ForgeRock (CVE-2021-35464 / CVE-2024-36401), folosită de aplicația de plăți a instituției. Prima urmă a compromiterii datează, conform capturilor publicate chiar de atacator, din 10 iulie, ora 15:23 (UTC).
De acolo, atacul s-a extins metodic. Investigatorii descriu compromiterea unui server IBM WebSphere printr-o interfață de management expusă fără autentificare, apoi a unei instanțe GitLab neactualizate, printr-o veche vulnerabilitate a componentei ExifTool (CVE-2021-22205). Din depozitele de cod ale GitLab, atacatorul a extras codul-sursă al unor sisteme proprietare esențiale: e-Terra, RENNS, module de plăți și componente GIS. A abuzat inclusiv platforma de monitorizare Zabbix pentru a-și deschide un canal suplimentar de acces.
Odată ajuns la planul de management al virtualizării (VMware vCenter), atacatorul a enumerat, potrivit raportului, 1.083 de mașini virtuale și a șters aproximativ o sută dintre ele (fun fact, nici ANCPI nu știa ce are în ogradă, estimând inițial undeva la 700 de mașini). A obținut acces la circa două milioane de înregistrări cu date personale ale utilizatorilor externi ai platformei de plăți (nume, adrese de e-mail și valori hash ale parolelor) și a copiat, pe un server aflat sub controlul său, discul virtual al unui controler de domeniu Active Directory. Conform propriilor afirmații consemnate în raport, nu a finalizat extragerea integrală a bazei Active Directory „din lipsă de timp”. Pe infrastructură au rămas un ransomware („bytetocrypt”), un implant de tip Command and Control (framework-ul Sliver, camuflat sub numele unui proces legitim, „auditd”) și un utilitar de tunelare pentru mișcare laterală (Ligolo-ng).
O singură veste este relativ bună: DNSC precizează că nu există dovezi privind accesul la baza de date Oracle Exadata, nucleul de date al instituției, și că o replică a acesteia se păstra, la interval de patru ore, într-un centru de date din Brașov.
Cronologia atacului (ora UTC)
▣ 10 iulie · 15:23 Acces inițial pe serverul de plăți, prin OpenAM/ForgeRock.
▣ 11 iulie · 19:48 Compromiterea unui server IBM WebSphere, printr-o interfață JMX neautentificată.
▣ 12 iulie · 14:55 GitLab neactualizat, exploatat prin ExifTool; se exfiltrează cod-sursă critic.
▣ 13 iulie · 21:09 Autentificare reușită dinspre producție către vCenter, cu un cont de administrator.
▣ 13-14 iulie Mișcări laterale, exfiltrare și ștergere de mașini virtuale, ștergere de backup-uri, criptare.
▣ 14 iulie · 05:45 Personalul IT al ANCPI constată incidentul, la peste 86 de ore de la primul acces.
Vulnerabilități vechi și cultura lui „merge și așa”
Partea cu adevărat gravă a raportului nu este iscusința atacatorului, ci starea infrastructurii pe care a găsit-o. DNSC descrie o instituție în care lipseau, cumulat, aproape toate straturile elementare de apărare. Însuși atacatorul, în interviuri acordate ulterior mai multor publicații, a susținut că nu a folosit „niciun 0day”, ci o vulnerabilitate veche, publică.
Deficiențe consemnate în raportul DNSC
▣ Echipamentul Web Application Firewall din fața aplicației de plăți păstra jurnalele de trafic doar 7 minute, mult sub necesarul minim pentru sisteme critice, ceea ce a limitat sever reconstituirea incidentului.
▣ Serverele care rulau aplicațiile nu aveau soluție antivirus. Produsul de securitate exista, dar rula exclusiv pe stațiile de lucru ale angajaților.
▣ Virtualizarea era administrată printr-o versiune de VMware vCenter ieșită din suport (6.0.0), fapt care a permis tehnici de enumerare netratate de mecanisme moderne de securitate.
▣ Nu exista un sistem centralizat de colectare a jurnalelor, de unde și un timp mediu de detecție (MTTD) de peste 86 de ore.
▣ Segmentare de rețea aproape inexistentă: din segmentul mașinilor virtuale de producție se putea ajunge direct la planul de management al virtualizării, ceea ce, într-o arhitectură corectă, nu ar fi trebuit să fie posibil.
▣ Reutilizarea acelorași credențiale de administrare pe zeci de echipamente din locații diferite; o singură parolă compromisă deschidea accesul către întreaga rețea.
▣ Soluția SIEM (FortiSIEM), menită să detecteze exact acest tip de atac, fusese instalată doar ca „proof of concept” și nu producea jurnale; în plus, stoca parole de echipamente prin criptare reversibilă.
Aceste constatări conturează un tipar mai important decât oricare vulnerabilitate individuală: cultura lui „merge și așa”. Un firewall care ține jurnalele șapte minute, un hipervizor scos din suport lăsat în producție, aceeași parolă pusă pe zeci de echipamente „pentru comoditate”: niciuna dintre acestea nu este o problemă de tehnologie de neînțeles. Toate sunt decizii, sau lipsuri de decizie, acumulate în timp. Software-ul se poate înlocui într-un an, dacă există voință și buget. Mentalitatea nu.
„Merge și așa” nu este o glumă de birou, ci un diagnostic. Este exact indicatorul care descrie nivelul de maturitate al IT-ului dintr-o instituție.
Există momente în care cea mai utilă contribuție pe care o poate aduce cineva este tăcerea. Sunt momentele în care ar trebui să lăsăm să vorbească specialiștii care lucrează efectiv la remedierea unei crize. Incidentul ANCPI a fost un asemenea moment. A fost, de altfel, unul dintre puținele incidente cibernetice majore din România devenite pe deplin publice, tocmai prin natura datelor vizate, evidența proprietăților, și prin amploarea blocajului.
În spațiul public, însă, reacția a urmat un tipar deja cunoscut. Un eveniment tehnic complex a fost comentat, în primele ore, de un număr impresionant de „experți” apăruți peste noapte, fenomen alimentat de o cultură mediatică în care publicul, obișnuit cu buletinele de știri construite pe senzațional, se simte deopotrivă competent să judece drone, geopolitică și securitate cibernetică. O parte dintre intervenții au fost oneste; altele au ținut mai degrabă de construcția de imagine pe seama unei crize în desfășurare.
Un aspect merită semnalat separat, pentru că depășește simpla dezbatere de opinie: în plină investigație, mai multe publicații și voci din domeniu au contactat și cineva chiar a intervievat persoana care revendica atacul.
Considerăm că, dincolo de valoarea jurnalistică a informării, această practică ridică o problemă reală de responsabilitate. A oferi unui atacator o platformă publică înseamnă a-i valida, involuntar, notorietatea, transformându-l dintr-un pseudonim de forum într-un „personaj” cu voce și versiune proprie. Iar acolo unde spargerea unei instituții a statului aduce vizibilitate, apare, previzibil, riscul emulării. Este un mecanism observat și în urmă cu 15-20 de ani, când notorietatea, nu neapărat câștigul financiar, era motorul multor intruziuni.
În contrast cu zgomotul, raportul amintește și de cei care au desfășurat investigația pe parcursul a șapte zile, într-un mediu în care unul dintre principalele obstacole a fost chiar lipsa de urme utilizabile. Este important de subliniat că documentul este neclasificat. Prin definiție, credem că o parte dintre metodele, tehnicile și instrumentele de investigare nu se regăsesc în el, tocmai pentru a nu fi deconspirate. Ceea ce este public reprezintă, prin urmare, doar o parte a imaginii; și chiar și această parte este suficient de gravă.
Nu doar ANCPI
Cazul Cadastrului nu este un accident izolat. La doar câteva zile distanță, pe 16-17 iulie, a fost confirmat un incident și la Ministerul Investițiilor și Proiectelor Europene (MIPE), unde aplicația „Achiziții Beneficiari Privați” a fost blocată, pe fondul unor temeri, dezmințite oficial, legate de baza de date a PNRR. În doar câteva zile, spațiul public a înregistrat mai multe incidente care au expus cetățeni și companii la blocaje și posibile pierderi.
Privite împreună, aceste episoade indică o problemă de sistem, nu o serie de ghinioane. Nivelul de dezvoltare a componentei IT din numeroase instituții publice a rămas în urmă cu ani buni. Un exemplu la îndemână este prezentarea online a unor instituții publice, de la spitale la agenții, a căror interfață pare desprinsă din urmă cu un deceniu. Problema nu este estetica unui site, ci ceea ce ea semnalează: aceeași filosofie a minimului efort, extinsă la întreaga direcție tehnică.
Nimic din analiza de față nu vizează actul profesional al instituțiilor menționate, serviciile pe care le prestează sau calitatea actului medical, acolo unde este cazul. Discuția privește strict starea și responsabilitatea componentei IT, două planuri distincte a căror confundare servește, de regulă, drept scuză pentru cei responsabili de partea tehnică.
Întrebarea incomodă: cine răspunde?
Dincolo de detaliile tehnice, incidentul ANCPI readuce în prim-plan o întrebare pe care administrația română o evită sistematic: cine răspunde? Într-o organizație privată, un incident de asemenea proporții ar declanșa, aproape automat, o cascadă de mecanisme: de la asigurarea de răspundere profesională, la despăgubiri și eventuale amenzi din partea autorităților de reglementare. În sectorul public, aceste pârghii lipsesc aproape complet: statul nu se sancționează pe sine, iar o eventuală amendă ar însemna, în practică, transferul unor bani dintr-un buget în altul.
Pentru funcțiile cheie din administrarea sistemelor critice ar trebui introduse mecanisme reale de responsabilizare precum răspundere individuală pentru consecințele directe ale deciziilor tehnice, o componentă de salarizare legată de performanță și evaluări periodice, transparente, ale competenței. Sunt principii care pot părea „corporatiste”, dar tocmai absența lor, întreținută vreme de peste trei decenii, a produs fragilitatea pe care raportul o documentează astăzi.
Întrebările rămân deschise. Ce măsuri va lua conducerea instituțiilor afectate față de direcțiile IT responsabile de starea sistemelor? Vor exista consecințe, administrative dacă nu de altă natură, sau, ca de fiecare dată, subiectul se va stinge odată cu ciclul de știri? Reamintim că o parte dintre vulnerabilitățile exploatate fuseseră semnalate anterior.
Experiența arată că memoria publică este scurtă. Peste câteva săptămâni, subiectul va fi înlocuit de următoarea criză, în timp ce structurile care au permis dezastrul vor rămâne, cel mai probabil, neschimbate. Tocmai de aceea, valoarea reală a raportului DNSC nu stă în listarea unui atac, ci în oglinda pe care o pune în față administrației.
Ce recomandă DNSC
Ultimele pagini ale documentului conțin, de altfel, partea cea mai utilă: un set de recomandări care sunt, în fapt, lista de măsuri elementare pe care orice organizație ar fi trebuit să le aibă implementate înainte de incident. Printre acestea: segmentarea strictă a rețelei și izolarea planului de management, autentificare multifactor obligatorie pentru conturile privilegiate, un management centralizat al jurnalelor (SIEM/XDR) funcțional, un proces riguros de actualizare a componentelor critice, aplicarea principiului privilegiului minim și, esențial în fața ransomware-ului, backup-uri offline și imuabile, testate periodic, alături de un plan de continuitate și de recuperare în caz de dezastru.
Sunt măsuri cunoscute, repetate în fiecare ghid de securitate din ultimul deceniu. Că ele lipseau dintr-o instituție care administrează evidența proprietăților unei țări întregi spune, în cele din urmă, mai mult decât orice detaliu tehnic din raport. Momentele de acest fel sunt exact cele în care merită să ascultăm specialiștii care le enunță și să tragem, în sfârșit, concluziile.