Vineri, 10 iulie 2026, la ora 15:23, un atacator a obținut acces la un server al Agenției Naționale de Cadastru și Publicitate Imobiliară. Agenția a observat marți, 14 iulie, la 05:45 — peste 86 de ore mai târziu. Până atunci copiile de siguranță fuseseră șterse, aproximativ 100 de mașini virtuale dispăruseră, iar fișierele de pe restul erau criptate cu ransomware-ul Black Basta.
Directoratul Național de Securitate Cibernetică a întocmit un raport tehnic asupra incidentului, prezentat pe larg în presa din România. Ce îl face util nu este cronica atacului, ci faptul că numește cauzele — iar fiecare dintre ele este o decizie pe care organizația o ia singură, cu mult înainte să apară un atacator.
Lanțul, pas cu pas
Punctul de intrare a fost o versiune extrem de învechită a platformei OpenAM, soluția de gestionare a identității și a accesului aflată în fața aplicațiilor agenției. Atacatorul a exploatat o vulnerabilitate critică cunoscută, și-a scris propriile comenzi pe server și a deschis o conexiune de tip reverse shell de la adresa publică a ANCPI către infrastructura proprie — pe un port ales astfel încât traficul să pară legitim, așa că firewall-ul nu a reacționat.
A urmat secvența previzibilă. Au fost colectate amprentele parolelor (hash-uri) din sistemul compromis, cu accent deliberat pe conturile echipei de dezvoltare, pentru că acestea aveau drepturi mai largi asupra aplicațiilor și infrastructurii. De acolo, atacatorul a căutat un punct de pivotare și a găsit serverul de monitorizare Zabbix — un echipament care, prin natura lui, comunică cu tot. Prin el a trecut peste restricțiile de comunicare dintre segmentele interne de rețea, exact cele care ar fi trebuit să împiedice acest lucru.
Până pe 13 iulie, întreaga structură a domeniului fusese copiată în fișiere JSON: un inventar de 16,4 MB al tuturor stațiilor de lucru și serverelor, o bază de utilizatori de 9,2 MB, grupurile de securitate, unitățile organizaționale, domeniile și politicile de grup. Fișierele au fost publicate ulterior pe forumuri de criminalitate cibernetică de actorul care operează sub numele ByteToBreach, activ din iunie 2025 ca broker de acces și comerciant de date furate.
Abia apoi a venit distrugerea. Atacatorul a localizat consola de management al copiilor de siguranță și a programat sarcini de ștergere, eliminând orice cale de recuperare rapidă, înainte de a prelua controlul platformei de virtualizare, de a scana toate cele 1.083 de mașini virtuale, de a șterge circa o sută dintre ele și de a cripta serverele critice.
Impactul operațional a fost total: eTerra, MyEterra, ePayment, Registrul Agricol Național, geoportalele folosite de primării și e-mailul agenției. Au fost exfiltrate aproximativ două milioane de înregistrări cu date personale, adrese de e-mail și parole criptate ale utilizatorilor externi ai platformei de plăți, împreună cu credențiale administrative de rețea și codul sursă al proiectelor interne din GitLab-ul propriu — inclusiv module de securitate și fișiere folosite la procesarea plăților.
O veste bună există totuși în raport: nu rezultă că baza de date centrală Oracle Exadata ar fi fost compromisă, iar datele erau replicate către un al doilea centru, la Brașov.
Cele trei cauze pe care le numește raportul
Concluziile preliminare ale DNSC sunt directe. Amploarea atacului a fost favorizată de software învechit, de o rețea internă foarte puțin segmentată și de aceleași parole de administrator folosite pe mai multe sisteme.
Alte două constatări explică cele 86 de ore. Serverele agenției nu aveau antivirus instalat — licența Bitdefender din rețea acoperea exclusiv stațiile de lucru ale angajaților. Și nu exista colectare centralizată a jurnalelor; firewall-ul pentru aplicații web păstra jurnalele de conexiune șapte minute. Când a ajuns echipa de răspuns, o parte din probe fusese ștearsă odată cu mașinile virtuale, iar alta pur și simplu expirase.
Raportul mai consemnează că DNSC transmisese către ANCPI alerte și recomandări privind vulnerabilități din infrastructura sa încă din octombrie 2024. Avertizările existau. Remedierea nu s-a făcut la timp.
Unde se regăsește fiecare punct în NIS 2
Citită încă o dată, lista arată ca o fișă de conformitate scrisă invers. Articolul 21 din NIS 2 — transpus în România prin OUG 155/2024 — cere entităților esențiale și importante măsuri tehnice și organizatorice proporționale cu riscul, iar cele trei cauze din raport se suprapun direct peste patru dintre ele: politici de analiză a riscului și de securitate a sistemelor informatice; gestionarea incidentelor; gestionarea și divulgarea vulnerabilităților; și politici privind criptografia și controlul accesului, inclusiv autentificare multifactor pentru accesul administrativ.
Segmentarea rețelei și gestionarea accesului privilegiat nu sunt opțiuni suplimentare în acest text. Sunt măsurile numite ca atare. O platformă de identitate expusă în internet, rulând o versiune veche de ani de zile, este o deficiență de gestionare a vulnerabilităților cu dată și avertizare documentate. Parolele de administrator refolosite sunt o deficiență de control al accesului. Șapte minute de jurnale și niciun server central de log fac imposibilă gestionarea incidentului — iar termenele de 24 de ore pentru avertizarea timpurie și 72 de ore pentru notificare — articolul 23 din Directivă, articolul 15 din OUG nr. 155/2024 — sunt greu de respectat când nimeni nu poate reconstitui ce s-a întâmplat.
Ce poate verifica o instituție publică din România luna aceasta
Nu un program. O listă de întrebări la care cineva poate răspunde până la final de octombrie.
- Ce servicii publici în internet și ce versiune rulează fiecare, de fapt? Nu versiunea din inventar — cea care răspunde acum pe port. Întâi platformele de identitate, gateway-urile VPN, serverele de mail, consolele de monitorizare și interfețele de administrare.
- Cine are drepturi de administrator, pe ce sisteme, și se repetă vreuna dintre parole în altă parte? Inclusiv conturile de serviciu: tocmai ele nu se rotesc niciodată, pentru că nimeni nu mai ține minte ce s-ar strica.
- Autentificarea multifactor este impusă pe accesul administrativ, pe VPN și pe accesul la consolele de management — fără o listă de excepții care a crescut pe tăcute?
- Poate o stație de lucru să ajungă direct la un server de producție? Poate serverul de monitorizare să ajungă în toate segmentele? Dacă răspunsul este da la oricare, segmentarea există pe schemă, nu în rețea.
- Unde ajung jurnalele și cât timp rămân acolo? Dacă răspunsul este „pe mașina respectivă", un atacator care șterge mașina șterge investigația.
- Unde este consola de backup, cine se poate autentifica la ea și există cel puțin o copie offline sau imutabilă? Atacatorul de la ANCPI a șters copiile de siguranță înainte să cripteze ceva, iar asta este practica standard acum.
- Există un proces scris de gestionare a vulnerabilităților, cu termene reale pe nivel de severitate, și o persoană nominalizată care poate aproba o repornire în afara programului ca să le respecte?
Ce confirmă un test față de un chestionar
Un chestionar de autoevaluare întreabă dacă rețeaua este segmentată, iar cineva răspunde că da, pentru că VLAN-urile există și regulile de firewall au fost scrise. Un test de penetrare intern răspunde la altă întrebare: pornind de la o singură stație compromisă sau de la un cont de serviciu cu prea multe drepturi, până unde se poate ajunge efectiv — și dacă nu cumva serverul de monitorizare este puntea dintre toate segmentele.
Diferența aceasta este exact distanța dintre rețeaua ANCPI așa cum era documentată și rețeaua ANCPI așa cum a găsit-o atacatorul. Același lucru este valabil pentru refolosirea parolelor, care pare o chestiune de politică internă până când un test arată că un singur hash recuperat deschide patru sisteme, și pentru inventarul serviciilor expuse, pe care o evaluare a suprafeței externe de atac îl construiește din exterior într-o după-amiază — exact cum a făcut-o atacatorul.
Partea incomodă a acestui raport este cât de banal a fost atacul. Nicio tehnică nouă, niciun zero-day. O platformă de identitate pe care nimeni nu o actualizase, un server de monitorizare care putea vorbi cu tot, parole de administrator folosite de două ori și nimeni care să se uite timp de trei zile și jumătate. Oricare dintre ele, închisă din timp, le-ar fi făcut pe celelalte trei mai grele. Pentru un audit de conformitate sub NIS 2, aceasta este lecția utilă: controalele care ar fi oprit incidentul sunt cele plictisitoare, iar ele se află deja în articolul 21.
Surse: G4Media — raportul DNSC privind atacul de la ANCPI · Go4IT — raportul tehnic intermediar DNSC, 24 iulie 2026 · Economedia — directorul DNSC despre atac
Detaliile tehnice de mai sus provin din raportul DNSC, așa cum a fost prezentat în presa din România; ClickSecure.AI nu le-a verificat independent. Atribuirea către ByteToBreach aparține DNSC și se bazează pe revendicarea publică și pe capturile de ecran ale atacatorului. Volumul înregistrărilor exfiltrate și situația bazei de date centrale provin din raportul intermediar și pot fi revizuite în versiunea finală.
Acest articol conține informații cu caracter general, nu consultanță juridică sau de reglementare.