Site hack-uit: Ce trebuie să faci?

Ghid practic și legal pentru instituții publice și firme private din România

Descoperi că site-ul tău a fost compromis. Pagina arată altfel, primești alerte de la Google, cineva îți semnalează că browserul îl marchează ca periculos. Sau, mai rău, nu descoperi nimic vizibil — dar cineva lucrează în fundal de săptămâni. Primul reflex este panica. Al doilea, de obicei greșit, este să „cureți" imediat și să speri că totul se rezolvă de la sine.

Un site hack-uit în România anului 2026 nu mai este doar o problemă tehnică internă. În funcție de tipul entității afectate — instituție publică sau firmă privată — există obligații legale cu termene clare, notificări obligatorii și sancțiuni pentru ignorarea lor. Cadrul există: Legea 362/2018, OUG 155/2024, GDPR. Ceea ce lipsește cel mai adesea este știința de a-l aplica în practică, în mijlocul crizei.

Acest ghid este organizat cronologic și pe tipuri de entitate. Nu înlocuiește un specialist în securitate cibernetică — dar îți oferă harta completă: ce faci în primele minute, ce ești obligat legal să faci în primele 24–72 de ore, cum arate o remediere corectă și ce documente trebuie să existe după incident. Fiecare secțiune distinge explicit între ce se aplică instituțiilor publice și ce se aplică firmelor private.

Cum știi că ai fost hack-uit

Semnele pe care le vede oricine

Cel mai evident semn de compromitere este defacement-ul: pagina principală a site-ului este înlocuită cu un mesaj al atacatorului, de obicei cu o declarație ideologică sau un simplu semn de prezență. Alte semne vizibile: redirecționări automate către site-uri străine (de obicei farmacii online false, jocuri de noroc sau conținut adult), conținut spam inserat în paginile existente fără să apară în panoul de administrare, pagini noi create pe domeniu fără intervenția administratorului, alerte de securitate afișate de Google Chrome sau Firefox la accesarea site-ului, sau notificări din Google Search Console că site-ul distribuie malware.

Semnele pe care nu le vede nimeni

Compromiterile periculoase sunt adesea complet invizibile. Un atacator care și-a atins scopul nu vrea să fie detectat — vrea să rămână. Web shell-urile sunt fișiere PHP plantate în directoare aparent inofensive (/images/, /cache/, /tmp/, /uploads/) care permit control complet asupra serverului prin browser, fără a apărea în niciun jurnal CMS. Conturile de administrator create discret, fișierele de sistem modificate subtil pentru a permite acces ulterior, script-urile care rulează în fundal pentru minare de criptovalute sau trimitere de spam — toate acestea pot funcționa săptămâni întregi fără ca administratorul să observe ceva.

Cum confirmi că ai fost compromise

Înainte de orice acțiune, confirmă că incidentul este real și nu un fals pozitiv:

• Google Search Console → secțiunea „Probleme de securitate" — dacă Google a detectat malware sau conținut înșelător pe site
• Sucuri SiteCheck (sitecheck.sucuri.net) — scan extern gratuit, detectează malware, liste negre, modificări suspecte
• VirusTotal (virustotal.com/gui/url) — verificare URL față de zeci de motoare antivirus
• Verificarea utilizatorilor administratori în panoul CMS — conturi necunoscute, create recent
• Inspecția logurilor de acces — cereri HTTP către căi neobișnuite, volume anormale de trafic, IP-uri suspecte cu activitate sistematică

Ce nu trebuie să faci în primele minute

Nu șterge logurile și nu curăța serverul înainte de a le exporta — logurile sunt dovezi și baza oricărei notificări legale ulterioare. Nu actualiza CMS-ul imediat fără un backup prealabil — poți suprascrie urme de atac necesare investigației. Nu anunța public compromiterea pe rețele sociale înainte de a evalua situația și de a lua măsuri — riscul de reputație se gestionează cu mesaj controlat, nu cu panică publică. Nu plăti niciun „serviciu de recuperare urgentă" contactat nesolicitat după incident — este o formă frecventă de fraudă secundară.

Protocolul de urgență: primele 72 de ore

Minutul 0–15: Izolarea

Dacă compromiterea este confirmată sau puternic suspectată, primul pas este oprirea daunelor active. Pune site-ul în modul de mentenanță sau offline complet. Scopul nu este să ascunzi problema — este să oprești orice activitate malițioasă în curs (redirecționări active, distribuire de malware vizitatorilor, exfiltrare de date) și să protejezi utilizatorii care ar putea fi afectați prin simpla accesare a site-ului.

Dacă nu poți pune site-ul offline singur, contactează imediat furnizorul de hosting și solicită suspendarea temporară a accesului public.

Prima oră: Documentarea criminalistică

Înainte de orice curățare, documentează tot ce este anormal:

• Screenshot-uri la toate paginile modificate, mesajele de eroare, avertismentele de securitate
• Export loguri WAF/firewall, access.log, error.log de la nivelul serverului, loguri CMS, loguri de autentificare
• Lista fișierelor modificate recent — pe cPanel: File Manager → sortare după dată modificare; prin SSH: find /public_html -mtime -30 -type f -name "*.php"
• Lista utilizatorilor administratori activi în CMS la momentul incidentului
• Notarea datei și orei exacte a primei detecții și a primelor semne observate

Această documentație nu este opțională dacă entitatea ta are obligații de notificare legală — este baza raportului tehnic.

Primele 24 de ore: Identificarea vectorului

Remedierea fără identificarea vectorului de intrare este incompletă. Dacă nu știi cum a intrat atacatorul, poate reveni pe același drum după ce „cureți". Vectorii cei mai frecvenți pentru Joomla și WordPress:

• Plugin sau template vulnerabil — cel mai comun; verifică dacă există CVE-uri publice pentru versiunile instalate
• Credențiale compromise — parola de administrator ghicită prin brute force sau preluată dintr-o scurgere de date anterioară
• Hosting nesecurizat — server shared cu alt site compromis, fișiere cu permisiuni prea largi (777), cont cPanel slab protejat
• Formular fără validare — injecție prin câmpuri de contact, comentarii, upload de fișiere
• Plugin abandonat — extensie neactualizată de ani de zile, cu vulnerabilități publice cunoscute

Logurile WAF (dacă există RSFirewall, Wordfence sau alt WAF activ) sunt cea mai rapidă cale de a identifica vectorul: caută cereri anormale în fereastra de timp anterioară primelor semne de compromitere.

Primele 48–72 de ore: Curățarea și restaurarea

Varianta preferată — restaurare din backup curat: Restaurează o copie a site-ului anterioară datei compromiterii. Verifică înainte că backup-ul nu este el însuși infectat (fișiere PHP în directoare de media, utilizatori admin inexplicabili). Aplică apoi toate actualizările și schimbă toate credențialele.

Varianta alternativă — curățare manuală (când nu există backup curat):

1. Elimină fișierele malițioase identificate (web shell-uri, backdoor-uri)
2. Reinstalează core-ul CMS din surse oficiale, suprascriind fișierele existente
3. Dezactivează și reinstalează plugin-urile și template-urile una câte una, din surse oficiale
4. Verifică baza de date pentru injecții (utilizatori falși, conținut spam, redirecționări)
5. Schimbă toate parolele și cheile de securitate

Obligatoriu după orice variantă:

• Update complet: CMS, toate plugin-urile, toate template-urile, la ultima versiune stabilă
• Schimbare parole: admin CMS, FTP/SFTP, cPanel, baza de date, email hosting
• Regenerare chei secrete CMS (Joomla: configurare → sistem; WordPress: wp-config.php)
• Activare sau reconfigurare WAF
• Activare autentificare în doi pași pentru toate conturile administrative

Cadrul legal: cine trebuie să notifice, pe cine și în cât timp

Aceasta este secțiunea care diferențiază cel mai mult cele două categorii de entități. Confuzia frecventă — „nu am obligație să anunț pe nimeni, e site-ul meu" — costă. Cadrul legal român și european există și se aplică.

Legislația aplicabilă

Legea 362/2018 transpune Directiva NIS europeană și definește obligațiile de notificare a incidentelor de securitate pentru operatorii de servicii esențiale (OSE) și furnizorii de servicii digitale. Stabilește DNSC ca autoritate competentă și CERT-RO ca punct național de contact.

OUG 155/2024 extinde sfera de aplicare a obligațiilor de securitate cibernetică, întărește rolul DNSC și introduce cerințe suplimentare pentru autoritățile publice și entitățile cu sisteme de importanță națională.

GDPR și Legea 190/2018 — obligație universală: dacă incidentul implică date cu caracter personal (și aproape orice site colectează cel puțin date prin formulare de contact sau cookie-uri cu consimțământ), notificarea ANSPDCP este obligatorie în 72 de ore de la constatare, indiferent de tipul entității.

Legea 58/2023 privind securitatea și apărarea cibernetică a României — cadrul strategic general, relevant pentru instituțiile cu sisteme clasificate sau de importanță pentru securitatea națională.

Instituțiile publice

Cine intră în această categorie: primării, consilii județene, școli, licee, colegii, universități de stat, spitale publice, instituții deconcentrate ale statului, orice autoritate publică locală sau centrală cu prezență online.

Obligația de notificare la DNSC este obligatorie, indiferent de gravitatea incidentului. Calitatea de instituție publică creează această obligație chiar dacă site-ul nu gestionează date sensibile sau infrastructură critică. Termenele:

• Notificare preliminară: 24 de ore de la constatarea incidentului
• Notificare completă cu loguri și IOC: 72 de ore
• Raport final: 30 de zile

Sancțiuni pentru nerespectare: amenzi între 5.000 și 100.000 lei conform art. 40 din Legea 362/2018. Posibilă răspundere penală dacă neglijența a favorizat accesul la date clasificate sau sisteme critice.

Particularitate importantă: chiar dacă site-ul este administrat de o firmă externă (agenție web, freelancer), responsabilitatea legală rămâne a instituției publice. Administratorul extern poate transmite notificarea în numele instituției, dar nu îi poate substitui răspunderea.

Firmele private

Firmele private operatori de servicii esențiale (OSE) — energie, transport, sănătate privată, bănci, asigurări, telecomunicații, apă, infrastructură IT — au aceleași obligații ca instituțiile publice: notificare DNSC în 24 de ore, raport complet în 72 de ore, raport final în 30 de zile.

Firmele private non-OSE — adică marea majoritate a IMM-urilor cu site de prezentare, magazin online sau platformă de servicii — nu au obligație de notificare la DNSC pentru orice incident, cu două excepții importante:

Prima excepție: date cu caracter personal compromise → notificare obligatorie la ANSPDCP în 72 de ore. Dacă site-ul colectează orice date personale prin formulare de contact, conturi de utilizator, comenzi online, newsletter sau cookie-uri cu consimțământ, și acele date au fost expuse, notificarea este obligatorie. Nu există prag minim de număr de persoane afectate sub care obligația să dispară.

A doua excepție: contractori ai statului sau ai unor OSE cu clauze contractuale de securitate — verifică contractul.

Sancțiuni GDPR pentru nenotificarea ANSPDCP: până la 10 milioane euro sau 2% din cifra de afaceri globală pentru nerespectarea obligațiilor de notificare (art. 83 alin. 4 GDPR). În practica ANSPDCP pentru IMM-uri: amenzi între 5.000 și 100.000 lei.

Tabel comparativ — obligații pe tip de entitate

Cum arată o notificare corectă la DNSC

Unde și cum se transmite

Notificarea se transmite prin portalul online al DNSC la adresa dnsc.ro, secțiunea „Raportare incidente". Alternativ, prin email la Această adresă de email este protejată contra spambots. Trebuie să activați JavaScript pentru a o vedea.. Notificarea poate fi transmisă de administratorul extern (agenția web, firma de IT) în numele entității afectate, cu menționarea explicită a acestui rol.

Notificarea preliminară (24 de ore) — ce trebuie să conțină

Notificarea preliminară nu trebuie să fie un raport tehnic complet — DNSC înțelege că investigația este în curs. Trebuie să conțină:

• Identitatea completă a entității raportoare (denumire, CUI, date de contact)
• Data și ora constatării incidentului
• Descrierea sumară: ce s-a observat, ce sisteme sunt afectate, ce tip de compromitere este suspectată
• Măsurile imediate luate (site offline, backup realizat, loguri exportate)
• Persoana de contact tehnică pentru corespondența ulterioară

Notificarea completă (72 de ore) — ce trebuie să conțină

• Vectorul de atac identificat (dacă este cunoscut la momentul raportării)
• Logurile relevante — WAF/firewall, access.log server, loguri CMS, loguri autentificare — exportate și atașate
• Indicatorii de compromitere (IOC): IP-uri atacator, fișiere malițioase identificate (cu căi complete), payload-uri capturate, hash-uri MD5/SHA256 ale fișierelor suspecte
• Cronologia incidentului — de la prima detecție suspectată până la momentul raportării
• Evaluarea impactului — date personale expuse (dacă e cazul), servicii afectate, utilizatori potențial expuși
• Măsurile de remediere implementate și cele planificate cu termene

Ce se întâmplă după notificare

DNSC confirmă primirea și poate solicita informații suplimentare. Pentru instituțiile publice, poate oferi asistență tehnică directă sau poate pune în legătură cu echipe specializate. Dacă incidentul are potențial de propagare (același vector afectează și alte site-uri sau sisteme), DNSC poate emite alerte către alte entități. DNSC nu sancționează pentru incident în sine — sancțiunile vizează nenotificarea sau neglijența gravă documentată.

Remedierea corectă pas cu pas

Pasul 1: Backup forensic înainte de curățare

Înainte de orice intervenție, realizează o copie completă a site-ului compromis — inclusiv fișierele malițioase. Această copie „forensică" servește două scopuri: analiza ulterioară pentru identificarea vectorului și eventuala procedură legală. Stocheaz-o separat de serverul de producție.

Pasul 2: Identificarea și eliminarea completă a persistenței

Curățarea superficială — eliminarea conținutului vizibil anormal — este cauza principală a recompromiterii. Un atac remedierea corectă înseamnă identificarea și eliminarea tuturor mecanismelor prin care atacatorul poate reveni:

• Web shell-uri — fișiere PHP în /images/, /cache/, /tmp/, /uploads/, /media/ și orice alt director de conținut; caută fișiere cu extensia .php care nu ar trebui să existe acolo
• Backdoor-uri în fișierele de sistem — funcții eval(base64_decode(...)), system(), exec() inserate în fișiere legitime (footer.php, index.php, configuration.php)
• Conturi administrator create de atacator — verifică toți utilizatorii admin, elimină cei necunoscuți, resetează parolele celor legitimi
• Cron jobs neautorizate — în cPanel → Cron Jobs; prin SSH: crontab -l
• Injecții în baza de date — redirecționări spam în tabele de opțiuni (WordPress: wp_options; Joomla: #__extensions), utilizatori falși în tabele de utilizatori

Pasul 3: Restaurarea din surse curate

Reinstalează core-ul CMS din surse oficiale (joomla.org, wordpress.org) — nu din backup-uri de origine necunoscută. Reinstalează plugin-urile și template-urile una câte una, din surse oficiale sau din cumpărăturile originale. Nu restaura fișierele de cod dintr-un backup potențial infectat — restaurează doar conținutul (imagini, documente) după verificare.

Pasul 4: Actualizare completă și schimbare credențiale

• Update CMS la ultima versiune stabilă disponibilă
• Update toate plugin-urile și extensiile active
• Update sau înlocuire template — dacă template-ul era vectorul (ca în cazul Helix 3 și CVE-2026-49049), dezinstalează-l complet și înlocuiește-l
• Schimbă toate parolele: administrator CMS, FTP/SFTP, cPanel/Plesk, baza de date, email hosting, orice cont asociat domeniului
• Regenerează cheile secrete ale CMS-ului
• Revocă toate sesiunile active

Pasul 5: Configurarea protecției post-incident

• WAF activ și configurat — RSFirewall pentru Joomla, Wordfence pentru WordPress, sau WAF la nivel de hosting/CDN (Cloudflare)
• Autentificare în doi pași pentru toate conturile administrative
• Restricție de acces la panoul de administrare pe IP — dacă IP-ul tău este fix, limita accesul la /administrator sau /wp-admin doar de la acel IP
• File integrity monitoring — RSFirewall și Wordfence au această funcție; alertează când fișierele de sistem sunt modificate
• Backup automat zilnic, stocat în locație separată (nu pe același server), cu verificare periodică a integrității

Pasul 6: Verificarea post-restaurare

Nu declara incidentul închis imediat după restaurare. Monitorizează activ cel puțin 2 săptămâni:

• Verifică zilnic logurile WAF pentru activitate anormală
• Rescansează site-ul cu Sucuri SiteCheck la 24 și 72 de ore după restaurare
• Verifică Google Search Console că alertele de securitate au dispărut
• Verifică listele negre (Google Safe Browsing, Spamhaus, MX Toolbox) și solicită eliminarea din ele dacă site-ul a fost indexat ca malițios

Documentația post-incident care te protejează

De ce contează documentația

Dacă incidentul ajunge în fața unui auditor, a DNSC, a ANSPDCP sau, în cazuri extreme, a instanței, documentația determină dacă ești „victimă neglijentă" sau „entitate care a acționat responsabil". Diferența poate fi sancțiunea sau absența ei.

Documentele care trebuie să existe după incident

Raportul intern de incident — cronologie completă: când s-a detectat, ce s-a constatat, ce acțiuni s-au luat și când, cine a fost responsabil pentru fiecare pas. Format liber, dar datat și semnat.

Corespondența cu autoritățile — copii ale notificărilor transmise la DNSC și ANSPDCP, cu dovada transmiterii (confirmare email, număr de înregistrare).

Logurile exportate și arhivate — WAF, server, CMS, autentificare — stocate separat de serverul de producție, cu integritate verificabilă.

Confirmarea măsurilor de remediere — document intern sau email de confirmare din partea administratorului tehnic că pașii de remediere au fost finalizați, cu date.

Dacă sunt implicate date personale: Registrul de evidență a încălcărilor — obligatoriu conform art. 33 alin. 5 GDPR, indiferent dacă incidentul a fost notificat sau nu la ANSPDCP.

Cât timp se păstrează documentația

Documentele legate de incidente de securitate: minim 3 ani (practică recomandată, acoperă termenele de prescripție administrative). Logurile de sistem: minim 1 an pentru instituții publice și OSE, minim 90 de zile recomandat pentru restul. Registrul GDPR de evidență a încălcărilor: minim 3 ani.

Ce trebuie actualizat în politica de securitate

Un incident este, printre altele, un audit forțat al procedurilor existente. Post-incident, trebuie revizuite sau create:

• Procedura de răspuns la incident (IRP) — dacă nu exista, trebuie creată acum; dacă exista, trebuie actualizată cu lecțiile din incident
• Politica de actualizare software — cât de des se verifică și se aplică actualizările CMS, plugin-uri, server
• Politica de backup — frecvență, locație stocare, procedură de testare periodică
• Managementul accesului — cine are acces admin, cu ce credențiale, cu ce nivel de privilegii
• Planul de continuitate — ce se întâmplă operațional dacă site-ul rămâne offline 24, 48, 72 de ore

Greșelile frecvente care costă

„Am șters virusul, site-ul e curat"

Cea mai frecventă și mai periculoasă greșeală. Eliminarea conținutului vizibil anormal fără identificarea vectorului și fără curățarea completă a persistenței lasă site-ul vulnerabil la recompromitere imediată — adesea în câteva ore sau zile. Un atacator care a plantat un web shell nu pierde accesul prin simpla ștergere a paginii de defacement.

„Nu am pierdut nimic important, site-ul e doar de prezentare"

Orice site compromis poate fi utilizat ca platformă pentru atacuri asupra altora — trimitere de spam, distribuire de malware, atacuri DDoS, phishing găzduit pe domeniu legitim. Răspunderea indirectă există. În plus, chiar dacă site-ul „e doar de prezentare", dacă are formular de contact sau cookie-uri cu consimțământ, colectează date personale și intră sub incidența GDPR.

„Nu trebuie să anunț pe nimeni, e problema mea"

Adevărat pentru firmele private non-OSE în privința DNSC — dar complet fals pentru obligația GDPR față de ANSPDCP dacă sunt implicate date personale. Și complet fals pentru orice instituție publică, indiferent de gravitate. Nenotificarea este o încălcare separată, sancționabilă distinct față de incident.

„Hostingul e responsabil"

Contractele de hosting standard exclud explicit răspunderea pentru compromiterea aplicațiilor instalate de client. Furnizorul de hosting răspunde pentru infrastructura fizică și pentru sistemul de operare al serverului — nu pentru securitatea Joomla, WordPress sau a oricărui CMS instalat. Responsabilitatea aplicației revine administratorului acesteia.

„Am backup, sunt acoperit"

Un backup nerecurent, necorelat cu data compromiterii sau el însuși infectat este mai periculos decât absența lui — poate reinstala compromiterea exact pe care o remediezi. Backup-ul trebuie: realizat automat zilnic, stocat în locație separată de serverul de producție, testat periodic (restaurat într-un mediu de test pentru a verifica integritatea), corelat cu data incidentului pentru a identifica copia anterioară compromiterii.

Concluzie

Există o diferență fundamentală între a fi victima unui atac cibernetic și a gestiona un incident de securitate. Prima este o situație tehnică. A doua este o responsabilitate organizațională și, în cazul instituțiilor publice sau al entităților cu date personale, o obligație legală cu termene și consecințe.

Protocolul nu este complicat — este secvențial. Izolezi. Documentezi. Notifici (dacă ești obligat). Identifici vectorul. Remediezi complet. Configurezi protecția. Arhivezi. Actualizezi procedurile.

Ceea ce complică lucrurile nu este tehnicitatea pasului, ci panica momentului. De aceea, harta de mai sus se citește înainte de incident — nu în mijlocul lui.

ABSOLUT WEB EXPERT SRL asigură servicii de administrare CMS, securitate cibernetică și conformitate legală pentru instituții publice și firme private. Pentru asistență în gestionarea unui incident de securitate sau pentru audit preventiv, ne puteți contacta prin formularul de contact de pe absolutweb.ro.

Acest articol a fost elaborat cu asistență AI și verificat editorial. Conținutul are caracter informativ general și nu constituie consultanță juridică. Pentru situații specifice, consultați un specialist în drept IT sau securitate cibernetică.