Sari la conținut
Braincap
← Toate articolele

Atacul ANCPI: ce arată analiza tehnică DNSC și ce înveți din ea

de Claudiu Hulea · IT Management Consultant

Ilustrație a unui atac ransomware asupra unei infrastructuri de virtualizare

DNSC a publicat analiza tehnică intermediară a atacului asupra ANCPI (nr. T66/22.07.2026). Confirmă un ransomware cu dublă extorsiune atribuit grupării ByteToBreach, în care un singur punct de intrare s-a transformat în compromiterea completă a organizației. Mai jos, faptele din raport și — mai important — ce trebuie să înveți din ele. Pentru cronologia din presă, vezi și articolul-știre despre incident.

Ce s-a confirmat, pe scurt

  • Tip de atac: ransomware cu dublă extorsiune (criptare + amenințarea publicării datelor), atribuit grupării ByteToBreach.
  • Distrugere: din 1.083 de mașini virtuale existente, atacatorul a șters aproximativ 100.
  • Aplicații afectate: e-Terra, ePayment, MyEterra, Registrul Proprietarilor, Titluri de Proprietate, RENNS, Registrul Agricol, Geoportal ș.a. — practic disponibilitatea întregii rețele ANCPI.
  • Recuperare: nu există decriptor (nici la DNSC, nici în surse deschise) — repunerea în funcțiune depinde de copiile de rezervă.

Lanțul de atac, pas cu pas

Lanțul de atac ANCPI în cinci etape (bazat pe analiza tehnică DNSC)

  1. Acces inițial (10 iulie) — printr-o aplicație de autentificare expusă în internet (openam.ancpi.ro), care deservea platforma de plăți. A fost punctul inițial de compromitere.
  2. Recunoaștere și mișcare laterală (13 iulie) — de pe mașina virtuală a aplicației epay, atacatorul a inițiat autentificări către vCenter (planul de management al virtualizării) — o sesiune dinspre segmentul de producție spre planul de management, semn clar de mișcare laterală.
  3. Control asupra virtualizării — pe vCenter a enumerat toate cele 1.083 de VM, a descărcat binare și s-a deplasat lateral prin SSH.
  4. Criptare — a rulat binarul de ransomware bytetocrypt pe mai multe servere ESXi, obținând întâi un shell interactiv prin exploatarea serverelor.
  5. Distrugere și exfiltrare — a șters ~100 de VM și a exfiltrat controlerul de domeniu Active Directory (mașina DC1, copiată prin scp pe un server al atacatorului), plus cod-sursă al unor aplicații.

Ce date au fost afectate

  • Disponibilitate: afectată masiv, prin ștergerea de mașini virtuale.
  • Exfiltrare confirmată: controlerul de domeniu Active Directory și cod-sursă al unor aplicații ANCPI.
  • Baza de date Oracle Exadata: potrivit DNSC, este puțin probabil ca atacatorul să dețină date din ea — capturile publicate nu indică acces la aceasta.

De ce a fost posibil (cauzele-rădăcină)

Aici e partea din care învață orice organizație. Potrivit DNSC, factorii cumulați au fost:

  • Aplicație de autentificare expusă direct în internet — punctul unic de intrare.
  • Segmentare insuficientă — s-a putut trece direct de la o VM de producție la planul de management (vCenter) și mai departe la hypervisoare.
  • Lipsa MFA pe conturile privilegiate — compromiterea unui singur cont a deschis toată infrastructura.
  • Antivirus doar pe stațiile de lucru, nu și pe servere.
  • Vizibilitate deficitară: WAF-ul din fața aplicației epay reținea jurnalele doar 7 minute — mult sub necesar, ceea ce a îngreunat reconstituirea atacului.
  • Recuperare condiționată de backup: fără copii offline/imuabile, restaurarea după ștergere devine foarte dificilă.

Concluzia DNSC e directă: lipsa unei politici coerente de management al infrastructurii, segmentarea slabă și gestionarea deficitară a credențialelor au permis ca un singur punct de compromitere să devină o compromitere totală.

Ce trebuie să facă orice companie

Recomandările DNSC, condensate în ce contează cel mai mult:

  • Securizează aplicațiile expuse în internet și pune-le într-o DMZ, separată de rețeaua internă.
  • Segmentează strict infrastructura — mai ales planul de management (vCenter, controlere de domeniu) — astfel încât o VM compromisă să nu ducă la mișcare laterală liberă.
  • MFA obligatoriu pe conturile privilegiate și pe accesul de la distanță; aplică privilegiul minim și acces „just-in-time“.
  • Monitorizare centralizată (SIEM/XDR) cu jurnale din hypervisor, Active Directory, firewall, DNS și servere — și retenție adecvată a log-urilor (nu 7 minute).
  • EDR pe servere, nu doar antivirus pe stații.
  • Copii de rezervă imuabile și offline (model 3-2-1), testate periodic — singura plasă de siguranță reală împotriva ștergerii/criptării.
  • Audit de securitate periodic și teste de penetrare pentru validarea măsurilor.

Primele două sunt și serviciile prin care începem, de regulă, cu un client: un audit de securitate IT arată unde ești vulnerabil, iar un test de penetrare confirmă ce e real exploatabil — exact tiparul care a lipsit aici.

Ce reținem

Incidentul nu a fost spectaculos din punct de vedere tehnic — a fost eficient pentru că apărarea avea găuri de bază: o aplicație expusă, segmentare slabă, fără MFA, logging insuficient și fără backup imuabil. Diferența dintre „un cont compromis“ și „toată organizația căzută“ o fac exact aceste controale.

Surse

Întrebări frecvente

Ce tip de atac a fost, potrivit analizei tehnice DNSC?

Un ransomware cu dublă extorsiune (criptare plus amenințarea publicării datelor), atribuit grupării ByteToBreach. Din 1.083 de mașini virtuale, atacatorul a șters aproximativ 100. Nu există decriptor, deci repunerea în funcțiune depinde de copiile de rezervă.

Cum a evoluat atacul, pas cu pas?

Accesul inițial (10 iulie) a fost printr-o aplicație de autentificare expusă în internet (openam.ancpi.ro). De acolo, atacatorul s-a mișcat lateral către vCenter (planul de management al virtualizării), a enumerat toate cele 1.083 de mașini virtuale, a rulat ransomware-ul bytetocrypt pe servere ESXi, a șters circa 100 de mașini și a exfiltrat controlerul de domeniu Active Directory și cod-sursă al unor aplicații.

De ce a fost posibil atacul (cauzele-rădăcină)?

Potrivit DNSC: o aplicație de autentificare expusă direct în internet, segmentare insuficientă (s-a putut trece de la o mașină de producție la planul de management), lipsa MFA pe conturile privilegiate, antivirus doar pe stații (nu și pe servere) și vizibilitate deficitară — WAF-ul reținea jurnalele doar 7 minute.

Ce trebuie să învețe o companie din acest incident?

Controalele de bază care au lipsit: securizarea aplicațiilor expuse (DMZ), segmentarea strictă a planului de management, MFA pe conturile privilegiate, EDR pe servere, monitorizare centralizată cu retenție adecvată a log-urilor și copii de rezervă imuabile și offline (model 3-2-1). Un audit de securitate și un test de penetrare validează aceste măsuri.