Magazinul online merge ciudat. Pagina de plată redirecționează uneori. Antivirusul din hosting nu semnalează nimic. Cineva șterge trei fișiere suspecte și declară problema rezolvată. Peste trei săptămâni revine exact ce era.
Diferența dintre „am șters ce am găsit” și „am verificat că nu mai există nimic” e diferența dintre o curățare și o iluzie. Curățare site infectat nu înseamnă să cauți până obosești. Înseamnă să ai un criteriu de terminare care produce dovezi, nu impresii. Un criteriu care poate fi repetat mâine și să dea același răspuns.
De ce ștergerea câtorva fișiere nu e o curățare
O infecție serioasă nu stă într-un singur fișier. Împrăștie sute de fragmente mici, în zeci de foldere, cu nume construite să nu fie găsite printr-o căutare simplă. Un script de backdoor poate fi împărțit în trei fișiere care par configurare PHP normală, apelate dintr-un al patrulea care pare un plugin inofensiv.
Dacă găsești fișierul de apel și îl ștergi, cele trei fragmente rămân. La prima reconstrucție a backdoor-ului, atacatorul importă fragmentele din nou. Tu crezi că ai rezolvat, el știe că nu.
Această tactică e documentată în ghidul OWASP de testare a securității web: obfuscarea codului și distribuirea sa în mai multe fișiere sunt tehnici standard de persistență pe care trebuie să le cauți explicit, nu să le găsești accidental. O curățare site infectat care nu acoperă toate folderele nu e o curățare completă.
Curățare site infectat: verificarea nucleului prin sume de control
WordPress pune la dispoziție un API de sume de control pentru fiecare versiune lansată. Trimiți versiunea ta, primești un obiect JSON cu hash MD5 pentru fiecare fișier din nucleu. Compari cu ce ai pe server. Dacă un fișier de nucleu diferă, e modificat.
Asta e singura metodă care îți dă un răspuns binar pe nucleu: fie fișierul e identic cu cel oficial, fie nu e. O inspecție vizuală nu îți dă asta. Mii de fișiere comparate în câteva minute, cu un script, fără opinii.
Documentația oficială WordPress descrie structura nucleului și ce fișiere sunt așteptate în fiecare folder. Orice fișier PHP în directorul nucleu care nu apare în lista oficială e suspect și trebuie investigat separat.
Curățare site infectat pe nucleu înseamnă înlocuirea completă a fișierelor modificate cu versiunile oficiale descărcate direct de la sursă, nu din cache sau din backup compromis. Backup-ul poate fi infectat dacă infecția e mai veche decât ultima copie.
Eșantionul nu ajunge: fișierele împrăștiate în zeci de foldere
Verificarea manuală pe eșantion e un pariu. Alegi 50 de fișiere dintr-un upload folder cu 3.000 de intrări și speri că ai ales fix pe cele infectate. Statistic, asta nu funcționează.
Automatizarea face ce omul nu poate face manual: parcurge complet. Fiecare fișier, fiecare folder, inclusiv cele imbricate adânc sau cu nume obscure. Căutarea de tipare în conținut, nu după nume de fișier: base64 decodat pe mai multe niveluri, eval pe șiruri construite dinamic, funcții PHP care execută comenzi de sistem.
Ce cauți concret:
Nu există fișier „prea mic” de verificat. Backdoor-urile de câteva linii sunt mai ușor de ascuns decât cele mari.
- Funcții PHP care execută comenzi sistem:
exec,shell_exec,system,passthruîn fișiere care nu ar trebui să le conțină - Blocuri
eval(base64_decode(...))sau variante cu urlencode, gzip - Fișiere cu dată de modificare recentă în foldere care n-ar fi trebuit modificate
- Fișiere cu permisiuni 777 pe server shared hosting
- Fișiere .php în folderul de upload, unde n-ar trebui să existe cod executabil
Ce se caută în baza de date
Codul poate sta și în baza de date. Opțiunea siteurl sau home modificată e imediată și vizibilă. Mai greu de văzut: opțiuni serializate cu cod JavaScript injectat, conținut de pagini cu iframe-uri ascunse, conturi de administrator create după data instalării. O curățare site infectat fără verificarea bazei de date e incompletă.
Sarcinile programate WordPress, tabelul wp_cron, pot conține hook-uri adăugate de atacator care reinfectează site-ul la un interval fix. Le ștergi manual, revin a doua zi. Dacă nu te uiți acolo, nu înțelegi de ce revine.
Verificarea conturilor: export complet din wp_users cu roluri, filtrat pe roluri cu drepturi ridicate, verificat vizual față de lista de utilizatori legitimi. Conturile create în zilele din jurul infecției sunt primul lucru de verificat.
Tiparul paravan: fișierele de configurare care permit ce par că blochează
Ăsta e tiparul pe care îl ratează aproape orice verificare superficială. Un fișier .htaccess în folderul de upload conține o regulă deny from all, urmată de o excepție pentru câteva extensii de fișier sau câteva nume specifice. Regula generală blochează. Excepția permite exact backdoor-ul.
Pare o măsură de securitate. E exact opusul. Atacatorul a adăugat blocarea generală ca să nu pară suspect, și a lăsat excepția pe care o folosește. Un .htaccess în upload nu e normal. Blochează-l complet sau șterge-l complet și înlocuiește cu unul curat.
Copia de rezervă vine înainte de orice ștergere
Nimic nu se șterge definitiv la prima trecere. Orice curățare site infectat serioasă începe cu o copie de rezervă completă, chiar dacă știi că e contaminată. Dacă ștergi un fișier care pare infectat și strici ceva funcțional, trebuie să poți da înapoi. Fără copie, nu poți.
Copia se face înainte de intervenție, inclusiv dacă știi că e infectată. Dacă totul merge prost după curățare, reconstruiești din backup contaminat și o iei mai lent. E mai bun decât să rămâi fără nimic.
Fișierele șterse în prima trecere se mută într-un folder de carantină, nu se șterg fizic. Dacă site-ul merge bine după 48 de ore, abia atunci se elimină definitiv.
Ce se schimbă obligatoriu după o execuție de cod străin
Tot ce putea fi văzut de codul atacatorului se tratează ca expus. Parolele bazei de date, cheile secrete WordPress din wp-config.php, credențialele FTP. Nu pentru că ai dovezi că au fost extrase, ci pentru că nu ai dovezi că n-au fost.
Credențialele de acces la panoul de hosting, la email și la orice cont asociat domeniului se schimbă. Dacă atacatorul a avut acces, a văzut tot ce era stocat sau transmis prin acel server.
Dacă site-ul procesează date personale ale clienților și există indicii că datele au fost expuse, există obligații de notificare conform GDPR. ANSPDCP are procedura și termenele pe site; un incident se raportează în 72 de ore de la constatare dacă există risc pentru persoanele afectate.
Nu e opțional și nu se decide după impresii. Dacă nu știi dacă datele au fost expuse, tratezi ca și cum ar fi fost.
Curățare site infectat: verificarea de după
Fiecare criteriu reluat de la zero, nu bifat din memorie. Suma de control pe nucleu rulată din nou. Căutarea de tipare în upload rulată din nou. Conturile verificate din nou. Sarcinile programate verificate din nou.
Paginile critice testate manual: homepage, pagina de produs, pagina de plată, pagina de cont. Traficul monitorizat 48 de ore pentru redirecționări sau cereri neașteptate. Dacă ceva a fost stricat în curățare, apare acum, nu peste o lună.
Curățare site infectat fără verificarea de după e o curățare neterminată. Criteriul de terminare e: am repetat toate verificările inițiale și nu am găsit nimic. Nimic altceva nu e suficient.
Unde ajută AI și unde decizia rămâne la om
AI e bun la recunoașterea tiparelor în volume mari de text. Parcurge zece mii de fișiere PHP și marchează pe cele cu structuri suspecte mai repede decât orice verificare manuală. Nu obosește, nu sare peste fișiere plictisitoare, nu ratează un folder cu un nivel de imbricare în plus.
Unde nu ajunge: decizia „ștergem sau nu”. Un fișier cu eval poate fi un plugin legitim care îl folosește pentru ceva inofensiv. Un fișier cu o dată de modificare recentă poate fi un fișier de cache normal. Decizia de ștergere o ia un om care înțelege contextul site-ului. AI-ul listează candidații, omul decide.
Limita onestă: dacă atacatorul a avut acces nedetectat luni de zile, nu ai cum să știi ce a mai schimbat și ce n-a schimbat. Reconstrucția de la zero, dintr-un backup verificat anterior infecției, poate fi mai ieftină și mai sigură decât o curățare site infectat cu istoric lung și incert.
Construim astfel de sisteme pentru firme mici și medii din România. Dacă ai un site care a trecut printr-o problemă de securitate și vrei să știi dacă s-a terminat sau continuă, scrie-ne la office@seoclub.ro. Prima discuție e despre ce s-a întâmplat și când, nu o prezentare generică.
Poți vedea și cum abordăm alte probleme de integritate a datelor, de la validarea datelor la import la sisteme care răspund numai din informații verificate.
