Incidentul ANCPI: cinci lecții de securitate cibernetică pentru orice organizație din România

Directoratul Național de Securitate Cibernetică a publicat, la 22 iulie 2026, analiza tehnică intermediară privind incidentul de securitate produs în infrastructura Agenției Naționale de Cadastru și Publicitate Imobiliară. Documentul, cu numărul T66 și clasificat drept neclasificat, reconstituie pas cu pas modul în care s-a desfășurat atacul.

Astfel de documente sunt rare. În mod obișnuit, despre incidentele majore aflăm doar concluzia — că un sistem a fost indisponibil sau că anumite date au ajuns public. Aici avem altceva: o cronologie tehnică detaliată, vectorii de compromitere, deciziile care au contat și, mai ales, deficiențele structurale care au permis unui singur punct de acces să se transforme într-o compromitere completă.

Pentru organizațiile care implementează cerințele NIS2 sau care evaluează nivelul de protecție a datelor cu caracter personal, raportul oferă ceva ce legislația nu poate oferi: un exemplu concret despre unde apar, în practică, vulnerabilitățile. Am parcurs documentul integral și am extras concluziile care ni se par cele mai utile, indiferent de sector sau de dimensiunea organizației.

Precizăm de la început: acest articol nu are scop critic la adresa instituției afectate. Ne bazăm exclusiv pe raportul public al DNSC și analizăm mecanismele, nu persoanele. Orice organizație care își evaluează onest infrastructura va recunoaște, în lista de mai jos, cel puțin una dintre situațiile descrise.

Ce s-a întâmplat, pe scurt

Investigația a confirmat un atac de tip ransomware cu dublă extorsiune — o metodă în care atacatorul mai întâi extrage datele, pentru a le folosi ca pârghie de șantaj, și abia apoi criptează sistemele. Incidentul a fost atribuit unei grupări de criminalitate informatică motivată financiar, care operează simultan ca broker de acces și comerciant de date compromise.

Cifrele consemnate în raport conturează dimensiunea evenimentului. Atacatorul a enumerat 1.083 de mașini virtuale existente în infrastructura de virtualizare și a șters aproximativ 100 dintre acestea. A extras, prin interogări succesive asupra unui serviciu de directoare, un volum estimat la circa două milioane de înregistrări conținând date cu caracter personal ale utilizatorilor înregistrați. A obținut acces la depozitele de cod-sursă ale unor aplicații proprietare esențiale. Iar la final a executat un binar de criptare asupra mai multor servere de virtualizare.

Impactul, așa cum este consemnat în raport, a constat în afectarea disponibilității întregii rețele a instituției.

Cronologia: cinci zile în care nimeni nu a observat nimic

Reconstituirea temporală este, probabil, partea cea mai instructivă a documentului.

10 iulie. Accesul inițial se produce prin exploatarea unei aplicații de autentificare expuse public în internet. Vulnerabilitatea folosită era cunoscută public din 2021 și avea deja remediere disponibilă. Atacatorul obține un shell interactiv și, ulterior, prin decriptarea unei chei de configurare, ajunge la credențialele de administrare stocate ale aplicației.

11 iulie. Compromiterea se extinde către un server de aplicații, prin exploatarea unei interfețe de management care nu solicita autentificare. Rezultatul este execuția de cod la distanță și o sesiune de control activă.

12 iulie. Este compromisă platforma internă de gestiune a codului-sursă, printr-o altă vulnerabilitate cunoscută și neremediată. Atacatorul extrage tabela de utilizatori, sparge una dintre parolele obținute și constată că aceasta era validă și pentru serviciul de autentificare de domeniu al organizației. Reutilizarea aceleiași parole pe sisteme distincte devine, din acest moment, motorul extinderii.

13 iulie. La ora 15:51 încep încercările de autentificare către platforma centrală de administrare a virtualizării. La ora 21:09 autentificarea reușește, cu un cont de administrator. Din acest punct, atacatorul are vizibilitate și control asupra întregului mediu virtualizat: enumeră mașinile virtuale, navighează direct prin volumele de stocare, cartografiază relațiile de privilegii din domeniu.

13–14 iulie. Sunt șterse copii de siguranță, sunt șterse mașini virtuale, este declanșată criptarea.

14 iulie, ora 05:45. Incidentul este constatat de echipa IT.

Între primul acces confirmat și momentul detectării au trecut aproximativ 86 de ore — peste trei zile și jumătate. Raportul consemnează explicit acest indicator ca MTTD, timpul mediu până la detectare, și îl leagă direct de absența unui sistem centralizat de colectare și stocare a jurnalelor.

Trei dimensiuni afectate simultan

Modelul clasic al securității informației vorbește despre confidențialitate, integritate și disponibilitate. Rareori un singur incident le atinge pe toate trei. Acesta le-a atins.

Confidențialitatea a fost pierdută fără echivoc. Au fost extrase înregistrări conținând nume, adrese de e-mail, identificatori unici de utilizator și valori hash ale parolelor. Din analiza formatului identificatorilor, DNSC a concluzionat că datele aparțin unor utilizatori externi ai platformei, adică unor persoane fizice. La acestea se adaugă expunerea codului-sursă al unor componente critice și publicarea, de către atacator, a unor dovezi pe forumuri specializate.

Disponibilitatea a fost pierdută prin criptare și prin ștergerea efectivă a mașinilor virtuale. Raportul precizează că nu au fost identificate instrumente de decriptare, nici la nivelul DNSC, nici în surse deschise.

Integritatea este dimensiunea cea mai dificil de evaluat. Raportul nu confirmă alterarea datelor, dar documentează faptul că atacatorul a deținut control administrativ deplin asupra infrastructurii de virtualizare și a cartografiat relațiile de privilegii din domeniu. Într-o astfel de situație, imposibilitatea de a demonstra că datele nu au fost modificate este ea însăși o problemă de conformitate.

Cele cinci lecții

1. Un incident nu începe atunci când sistemele se opresc

Cea mai răspândită percepție în organizații este că un incident începe în momentul în care sistemele devin indisponibile sau fișierele apar criptate. Raportul arată exact contrariul: ransomware-ul a fost etapa finală a unui proces care rula deja de zile. Înainte de orice efect vizibil, atacatorul obținuse acces privilegiat, compromisese componente critice și se deplasase lateral prin infrastructură.

Consecința pentru conformitate este directă. Obligațiile privind monitorizarea, detectarea și răspunsul la incidente nu se activează în momentul în care activitatea este deja afectată. Capacitatea de a identifica un atac în fazele incipiente este ceea ce separă un incident gestionabil de o compromitere totală.

Un detaliu din raport ilustrează problema mai bine decât orice explicație teoretică: echipamentul care asigura funcția de Web Application Firewall, amplasat tocmai pentru a proteja aplicația expusă, avea configurată o perioadă de retenție a jurnalelor de șapte minute. Nu șapte zile, nici șapte ore. În lipsa acestor date, reconstituirea retroactivă a evenimentelor a fost sever limitată, iar DNSC menționează explicit vizibilitatea insuficientă drept unul dintre obstacolele majore ale investigației.

2. O singură vulnerabilitate explică rareori un incident major

Raportul nu descrie exploatarea unei singure breșe, ci un lanț de compromitere. Aplicație expusă și neactualizată. Credențiale obținute din configurația acesteia. Un al doilea sistem compromis printr-o interfață de management fără autentificare. Un al treilea, printr-o vulnerabilitate publică neremediată. O parolă spartă, reutilizată pe un serviciu complet diferit. Și, în final, accesul la planul de administrare a virtualizării.

Fiecare verigă, luată separat, ar fi fost gestionabilă. Împreună, au produs efectul descris.

Acesta este și motivul pentru care standardele actuale de securitate insistă pe suprapunerea mai multor controale. Reziliența nu vine din existența unei singure măsuri, ci din capacitatea mai multor măsuri de a funcționa împreună și de a compensa reciproc.

Un factor determinant, consemnat ca atare de DNSC, a fost segmentarea aproape inexistentă a rețelei interne. Faptul că din segmentul mașinilor virtuale de producție s-au putut iniția sesiuni direct către planul de management al virtualizării este o conectivitate care, într-o arhitectură corect segmentată, pur și simplu nu ar fi trebuit să existe.

La aceasta se adaugă o observație despre ciclul de viață al infrastructurii: atât componentele de securitate perimetrală, cât și platforma de virtualizare rulau versiuni ieșite din suportul producătorului, care nu mai primeau actualizări de securitate.

3. Backup-ul există aproape peste tot. Întrebarea este dacă rezistă unui atac

Prima întrebare care se pune după un incident de tip ransomware este dacă existau copii de siguranță. Aproape întotdeauna răspunsul este afirmativ. Problema apare la a doua întrebare.

Raportul documentează faptul că atacatorul a accesat și a șters mai multe copii de rezervă, printre care și copii ale unor componente esențiale de infrastructură. Atacatorii moderni vizează în mod deliberat infrastructura de backup înainte de a declanșa criptarea, tocmai pentru a elimina alternativa de recuperare.

Recomandările DNSC din finalul raportului sunt, în această privință, foarte concrete și structurate pe trei niveluri. Un backup operațional, destinat restaurării rapide după incidente minore, cu retenție de minimum 30 de zile. Un backup imuabil, stocat cu politică de tip write once, read many sau cu blocare la nivel de obiect, care nu poate fi șters înainte de expirarea retenției, recomandată la 14–30 de zile. Și un backup offsite, într-o locație fizică distinctă sau în cloud, cu transfer criptat și retenție de 60–180 de zile.

La fel de important: testarea periodică a restaurării. Existența unei copii nu garantează nimic. Doar un proces de restaurare verificat efectiv poate oferi o estimare realistă a timpului de reluare a activității. Pentru conducere, aceasta nu mai este o decizie tehnică, ci una care privește direct continuitatea operațională.

4. Conturile privilegiate sunt zona critică de risc

Raportul descrie obținerea unor privilegii extinse și utilizarea lor pentru compromiterea componentelor esențiale. Dar mecanismul care a făcut extinderea posibilă este mai banal decât ne-am aștepta.

Din analiza datelor recuperate rezultă o practică extinsă de reutilizare a acelorași credențiale de administrare pe multiple echipamente și sisteme, situate în subrețele și locații diferite. Odată compromisă o singură sursă de credențiale, accesul s-a extins fără a mai fi necesară exploatarea individuală a fiecărui sistem. În plus, o parte dintre parolele stocate se aflau într-un format criptat reversibil, ceea ce a permis obținerea lor directă în clar.

De aici derivă concluzia pe care raportul o formulează explicit: securitatea identității digitale și monitorizarea autentificărilor trebuie tratate ca elemente critice de continuitate operațională, întrucât incidentul a demonstrat impactul major pe care îl poate avea compromiterea unui singur cont privilegiat asupra întregii infrastructuri.

Măsurile care contrabalansează acest risc sunt cunoscute și nu presupun investiții mari: parole unice pentru fiecare sistem, autentificare multifactor pentru conturile privilegiate și pentru accesul de la distanță, aplicarea principiului privilegiului minim, revizuirea periodică a drepturilor de acces și eliminarea conturilor tehnice cu privilegii excesive. Raportat la costul implementării, autentificarea multifactor rămâne una dintre cele mai eficiente măsuri disponibile.

5. Conformitatea nu se demonstrează prin documente, ci prin capacitatea de răspuns

Poate cea mai importantă concluzie este că existența politicilor și a procedurilor nu este suficientă dacă acestea nu funcționează în momentul în care organizația este efectiv atacată.

Segmentarea rețelei, monitorizarea continuă, planurile de răspuns la incidente și testarea recuperării sunt mecanisme care trebuie validate periodic, nu doar documentate. Un document aprobat și un control care funcționează sunt două lucruri diferite, iar diferența dintre ele devine vizibilă exact în momentul cel mai nepotrivit.

Tocmai de aceea, implementarea cerințelor NIS2 nu ar trebui privită ca un exercițiu de conformitate documentară, ci ca un proces prin care organizația își verifică și își consolidează capacitatea reală de a răspunde unui incident.

Dimensiunea privind protecția datelor cu caracter personal

Pentru organizațiile care au desemnat un responsabil cu protecția datelor, incidentul are o a doua citire, la fel de importantă.

Extragerea a aproximativ două milioane de înregistrări conținând nume, adrese de e-mail, identificatori de utilizator și valori hash ale parolelor reprezintă o încălcare a securității datelor cu caracter personal în sensul Regulamentului general privind protecția datelor. Faptul că parolele erau stocate sub formă de hash reduce riscul, dar nu îl elimină — mai ales atunci când o parte dintre aceste valori pot fi supuse unor atacuri de tip cracking, așa cum raportul însuși menționează.

O astfel de situație declanșează, în principiu, o secvență previzibilă de obligații: evaluarea riscului pentru drepturile și libertățile persoanelor vizate, documentarea internă a incidentului în registrul dedicat, notificarea autorității de supraveghere — în regulă generală în termen de 72 de ore de la luarea la cunoștință, conform articolului 33 — și, atunci când riscul este ridicat, informarea persoanelor vizate potrivit articolului 34. La acestea se adaugă documentarea măsurilor de remediere, ca expresie a principiului responsabilității.

Riscul de sancțiune există, atât în cadrul NIS2, cât și în cel al protecției datelor. Dar experiența noastră arată că organizațiile care tratează subiectul pornind de la teama de amendă ajung la documentație formală și la controale care nu funcționează. Cele care pornesc de la întrebarea „ce se întâmplă concret dacă mâine suntem atacați” ajung, în mod paradoxal, și la o conformitate mai solidă.

NIS2 și GDPR cer, în bună măsură, aceleași lucruri

Una dintre confuziile frecvente în organizații este că securitatea cibernetică și protecția datelor sunt două agende separate, gestionate de echipe diferite, cu bugete diferite.

Controalele care ar fi limitat acest incident spun altceva. Actualizarea sistemelor expuse, autentificarea multifactor, segmentarea rețelei, copiile de siguranță imuabile și testate, jurnalizarea centralizată — toate se regăsesc, în paralel, atât în măsurile tehnice și operaționale prevăzute de OUG nr. 155/2024, care transpune Directiva NIS2, cât și în articolul 32 din Regulamentul general privind protecția datelor, care cere „măsuri tehnice și organizatorice adecvate” riscului.

Articolul 32 menționează expres criptarea și pseudonimizarea, capacitatea de a asigura confidențialitatea, integritatea, disponibilitatea și rezistența continuă a sistemelor, capacitatea de a restabili disponibilitatea datelor în timp util în caz de incident, precum și un proces de testare și evaluare periodică a eficacității măsurilor. Sunt, practic, aceleași cerințe, formulate din altă perspectivă.

Concluzia practică: o organizație care își construiește serios conformitatea NIS2 avansează simultan și pe zona de protecție a datelor. Și invers.

Șase verificări de la care se poate începe

Nu propunem un plan complet, ci punctele de plecare care, în experiența noastră, produc cea mai mare reducere de risc raportat la efort:

1. Suprafața de expunere. Ce servicii ale organizației sunt accesibile din internet și în ce stare de actualizare se află fiecare? Un inventar onest este primul pas.
2. Managementul actualizărilor. Există un proces recurent, cu responsabil desemnat, pentru componentele critice? Mai există în producție componente ieșite din suportul producătorului?
3. Autentificarea multifactor. Este activată pe conturile privilegiate, pe accesul VPN și pe serviciile critice accesibile de la distanță?
4. Segmentarea rețelei. Poate cineva ajunge, din zona de producție, direct la sistemele de administrare? Există o zonă separată pentru resursele expuse public?
5. Copiile de siguranță. Există cel puțin o copie care nu poate fi ștearsă înainte de expirarea retenției? Când a fost ultima dată testată efectiv o restaurare?
6. Jurnalizarea și răspunsul la incidente. Sunt jurnalele colectate centralizat? Cât timp sunt păstrate? Există un plan de răspuns care a fost exersat, nu doar redactat?

O precizare despre testele de securitate. Un test de penetrare este o decizie de management, nu o obligație imediată, iar utilitatea lui depinde de nivelul de maturitate deja atins. Într-o organizație care nu are încă inventarul sistemelor expuse și nu are autentificare multifactor pe conturile privilegiate, un pentest va confirma ceea ce se știe deja. Primul pas util este, de regulă, recuperarea și analiza rapoartelor existente de la furnizorii de servicii IT.

Descărcați analiza în format vizual

Am sintetizat concluziile de mai sus într-un material vizual de 12 pagini, structurat pe cele cinci lecții, cu cronologia incidentului, maparea pe cerințele NIS2 și pe articolul 32 GDPR, precum și lista de verificări. Poate fi folosit ca suport de discuție intern, inclusiv în ședințe de conducere.

Descărcați analiza în format PDF — „Cinci lecții dintr-un incident de securitate cibernetică” (12 pagini)

Cum vă putem ajuta

Dacă parcurgând lista de mai sus ați identificat zone neacoperite, este exact motivul pentru care am scris acest articol. Sprijinim organizațiile din România în patru direcții:

Responsabil NIS2 externalizat. Preluăm rolul și coordonarea operațională a conformității cu OUG nr. 155/2024, de la analiza de încadrare și notificarea la DNSC, până la implementarea măsurilor și menținerea lor în timp.

DPO externalizat. Acoperim integral funcția de responsabil cu protecția datelor: registre de prelucrare, evaluări de impact, contracte cu împuterniciții, transferuri internaționale și gestionarea incidentelor de securitate a datelor.

Evaluare și audit de conformitate. Analiză de încadrare, evaluarea nivelului de maturitate pe domenii și un plan de măsuri prioritizat în funcție de risc și de efortul de implementare — nu o listă generică, ci o ordine de acțiune adaptată organizației.

Politici, proceduri și instruire. Documentație aplicabilă, redactată pentru realitatea organizației, împreună cu programe de conștientizare pentru personal și simulări de tip phishing.

Pentru o discuție privind încadrarea organizației dumneavoastră și nivelul actual de pregătire, ne puteți scrie la contact@gdprcomplet.ro sau ne puteți contacta la +40 745 518 754.

Surse și precizări

Articolul se bazează exclusiv pe Analiza tehnică intermediară cu privire la incidentul de securitate cibernetică produs în infrastructura ANCPI, document neclasificat nr. T66 din 22.07.2026, publicat de Directoratul Național de Securitate Cibernetică. Raportul are caracter intermediar, iar investigația era în desfășurare la data publicării.

Cadrul normativ de referință: Directiva (UE) 2022/2555 (NIS2), Ordonanța de urgență a Guvernului nr. 155/2024, aprobată prin Legea nr. 124/2025, Ordinele Directorului DNSC nr. 1/2025, 2/2025 și 3/2025, precum și Regulamentul (UE) 2016/679 și Legea nr. 190/2018.

Material informativ. Nu constituie consultanță juridică pentru o situație individuală.