La sfârșitul lui iulie 2026, atacatorii au început să exploateze un zero-day în N-able N-central — platforma de monitorizare și administrare de la distanță (RMM) pe care mii de furnizori de servicii IT administrate (MSP) o folosesc pentru a instala actualizări, a monitoriza și a accesa de la distanță serverele și stațiile de lucru ale clienților. Vulnerabilitatea, identificată drept CVE-2026-18577, este un bypass de autentificare: nu e nevoie de parolă furată, de e-mail de phishing sau de malware la tine în rețea. Atacatorul intră direct în consola care are deja drepturi de administrator peste infrastructura ta.
Dacă firma ta externalizează administrarea IT — și majoritatea IMM-urilor din România, plus multe organizații mari, o fac — incidentul acesta nu este o poveste despre software-ul altcuiva. Este o demonstrație a propriei tale suprafețe de atac.
Ce s-a întâmplat, de fapt
Conform N-able și cercetătorilor care au urmărit campania, cronologia a fost scurtă și incomodă. Furnizorul a observat activitate neobișnuită pe 31 iulie și a confirmat exploatarea activă pe 2 august. Vulnerabilitatea s-a dovedit a fi un bypass al patch-ului pentru o problemă anterioară (CVE-2026-18556): atacatorii au studiat corecția și au găsit o cale de a o ocoli.
Odată intrați într-un server N-central, atacatorii au făcut exact ce poate face un tehnician MSP: au folosit funcția legitimă de acces la distanță Take Control pentru a se conecta la sistemele administrate prin consolă, apoi au înregistrat un tunel Cloudflare ca serviciu pe acele echipamente, ca să-și păstreze accesul chiar și după închiderea breșei. N-able a confirmat că atacatorii au ajuns în rețelele clienților, a lansat două hotfix-uri în succesiune rapidă (versiunea 2026.3.1.7, apoi un al doilea hotfix cu măsuri suplimentare), iar CISA a adăugat vulnerabilitatea în catalogul KEV al vulnerabilităților exploatate activ, dând agențiilor federale americane doar câteva zile pentru instalarea corecției.
Reține mecanismul: nu a fost nevoie de niciun exploit pe calculatoarele victimelor. Relația de încredere a fost calea de atac.
De ce e o problemă NIS 2, nu doar una de IT
NIS 2 — transpusă în România prin OUG 155/2024, cu domeniul de aplicare extins ulterior prin Legea 124/2025 — transformă securitatea lanțului de aprovizionare într-o obligație legală explicită, nu într-un „ar fi bine". Entitățile esențiale și importante trebuie să trateze, în cadrul măsurilor de gestionare a riscurilor, securitatea relațiilor cu furnizorii direcți și cu prestatorii de servicii. Directiva menționează explicit furnizorii de servicii administrate (MSP/MSSP), tocmai din cauza accesului privilegiat pe care îl dețin.
Trei consecințe contează pentru companiile din România:
- Rămâi responsabil. Externalizarea administrării IT nu externalizează răspunderea. Dacă un atacator ajunge la sistemele tale prin instrumentele MSP-ului, incidentul este incidentul tău, cu obligațiile tale de raportare către DNSC (avertizare inițială în 24 de ore, notificare de incident în 72 de ore) și cu sancțiunile tale potențiale — până la 10 milioane € sau 2% din cifra de afaceri mondială pentru entitățile esențiale, respectiv 7 milioane € sau 1,4% pentru cele importante.
- Conducerea răspunde personal. OUG 155/2024 preia prevederile directivei privind răspunderea managementului: conducerea trebuie să aprobe măsurile de gestionare a riscurilor, să supravegheze implementarea lor și poate fi trasă la răspundere pentru neîndeplinire — inclusiv pentru măsurile de lanț de aprovizionare.
- MSP-ul tău poate fi el însuși entitate NIS 2. DNSC poate desemna drept entitate NIS 2 orice organizație cu rol critic într-un lanț de aprovizionare, indiferent de dimensiune. Mai multe analize de conformitate anticipează că deficiențele din lanțul de aprovizionare vor deveni unul dintre principalele motive de sancționare pe măsură ce controalele DNSC se intensifică din 2026 — o estimare venită din zona de consultanță, nu o statistică oficială, dar plauzibilă având în vedere cum evoluează etapa de aplicare.
Cele trei pârghii pe care ți le dă NIS 2: contract, audit, verificare
Ce înseamnă „gestionarea riscului de furnizor" în practică, atunci când furnizorul deține o consolă echivalentă cu drepturi de administrator de domeniu peste rețeaua ta?
1. Clauze contractuale de securitate. Contractul cu furnizorul IT trebuie să înceteze să fie doar un SLA despre timpi de răspuns. Are nevoie de: cerințe minime de securitate pentru infrastructura proprie a furnizorului (MFA peste tot, termene de patch pentru instrumentele lui, segmentarea rețelei de administrare); o obligație fermă de a te notifica despre incidentele de securitate care îi afectează sistemele, într-un număr definit de ore — nu un „fără întârzieri nejustificate" lăsat nedefinit; lista subcontractanților și a părților terțe cu acces; și prevederi clare de ieșire din contract, care să acopere returnarea credențialelor și dezinstalarea agenților.
2. Drept de audit și de testare. O clauză pe hârtie nu valorează mult dacă nu o poți verifica niciodată. Negociază un drept explicit de a audita controalele furnizorului — chestionare cel puțin, audituri independente sau la fața locului pentru furnizorii critici — și dreptul de a include căile lui de acces în propriile tale teste de securitate. Un test de penetrare care se oprește la granița „acela e sistemul MSP-ului, în afara scope-ului" testează o ficțiune: atacatorii, demonstrabil, nu respectă acea graniță. Un pentest de infrastructură ar trebui să modeleze exact scenariul N-central — ce poate face cineva din platforma de administrare și dacă ai detecta asta.
3. Verificarea accesului privilegiat al terților. Acesta este controlul pe care cele mai multe organizații îl sar. Concret: păstrează un inventar al fiecărui cont extern, agent și instrument RMM cu acces privilegiat în mediul tău; impune MFA pe conturile furnizorului din sistemele tale, nu doar din ale lui; restricționează accesul de rețea al platformei de administrare la strictul necesar; loghează și alertează sesiunile de control la distanță (o conexiune Take Control la ora 03:00 trebuie să trezească pe cineva); și verifică trimestrial dacă fiecare acces mai are motiv să existe. Conturile de furnizor uitate și agenții dormanți sunt exact ce au folosit atacatorii din campania N-central ca să persiste.
Întrebări de trimis furnizorului IT săptămâna aceasta
- Folosiți N-central sau alt RMM? Ce versiune, și când ați aplicat hotfix-urile din august?
- Este MFA impus pe toate conturile de tehnician, inclusiv pe accesul API?
- Cum ați afla — și cât de repede ne-ați anunța — dacă platforma voastră de administrare ar fi compromisă?
- Care dintre angajații și subcontractanții voștri pot deschide astăzi o sesiune la distanță către sistemele noastre?
- Acceptați la reînnoire o clauză contractuală de audit și testare?
Un furnizor serios răspunde într-o zi. Răspunsurile evazive sunt, în sine, un rezultat de evaluare a riscului.
Dacă vrei un punct de plecare structurat, checklist-ul nostru NIS 2 / DORA acoperă cerințele de lanț de aprovizionare alături de celelalte măsuri, iar echipa de audit și conformitate poate compara contractele tale actuale cu furnizorii față de ce cere efectiv OUG 155/2024. Campania N-central nu va fi ultima dată când un atacator alege platforma de administrare în locul ușii din față — este pur și simplu cea mai ieftină cale de intrare.
Acest articol oferă informații generale, nu consultanță juridică. Surse: The Hacker News, BleepingComputer, Rapid7, Help Net Security, CMS Law despre Legea 124/2025.