Site reinfectat mereu? De ce reapare virusul după curățare

Ai plătit pe cineva sau ai stat tu nopți întregi să cureți site-ul. A mers. Te-ai uitat în Google, nu mai apărea niciun avertisment, paginile de spam dispăruseră, ai răsuflat ușurat. Trei zile mai târziu intri pe propriul site și ești redirecționat iar către o pagină de pariuri, sau găzduirea îți scrie din nou că serverul trimite spam. Senzația e de neputință: parcă nu mai ai control pe propria afacere online.

Vestea proastă e că nu ai avut ghinion. Vestea bună e că reinfectarea are de fiecare dată o cauză concretă, pe care o poți identifica și închide. Mai jos îți arăt de ce curățarea singură aproape niciodată nu e de ajuns, care sunt ușile pe care revine virusul (backdoor-uri, useri admin ascunși, taskuri programate, intrări în baza de date) și de ce doar o protecție la nivel de rețea, plus câteva obiceiuri simple, oprește cu adevărat runda a doua.

Curățarea șterge efectele. Reinfectarea vine din mecanism

Aici e neînțelegerea de la care pornește totul. Când vezi redirecturi, pagini de spam sau fișiere ciudate, acelea sunt efectele infectării. Le ștergi și site-ul pare curat. Dar atacatorul nu trăiește în efecte, ci în mecanismul de revenire pe care l-a lăsat dinadins, ca să poată reveni după ce tu cureți. El știe că vei observa spamul și îl vei șterge, așa că, încă de la prima vizită, își instalează discret o cheie de rezervă.

Gândește-te la o spargere reală. Hoțul a intrat pe geam, a furat ce a vrut, dar înainte să plece a lăsat o cheie sub preș și a stricat zăvorul de la ușa din spate. Tu repari geamul (ștergi paginile de spam) și crezi că ești în siguranță. El se întoarce liniștit pe ușa din spate. Cât timp nu găsești cheia de sub preș, oricât de bine ai curăța, te trezești iar cu el în casă. Cheia de sub preș, în lumea site-urilor, are mai multe forme. Hai să le luăm pe rând.

Pe unde revine virusul, concret

Acestea sunt cele mai frecvente ascunzători. Rar le ai pe toate, dar e suficientă una singură ca site-ul să se reinfecteze la nesfârșit.

Fișiere backdoor lăsate în urmă

Un backdoor este un fișier mic, deseori cu nume care pare nevinovat (ceva de tipul wp-cache.php, class-db.php sau un nume aproape identic cu un fișier legitim), strecurat printre miile de fișiere reale ale site-ului. Rolul lui e unul singur: să-i dea atacatorului acces oricând, fără să mai spargă nimic. Cât timp acel fișier există, el poate reinjecta tot codul rău cu o singură comandă. De aceea ștergerea paginilor de spam nu schimbă nimic: izvorul e în altă parte. Backdoor-urile stau des în wp-content/uploads (unde nu te aștepți la fișiere de program) sau în mai multe copii, ca să fie greu de eliminat complet.

Useri administratori pe care nu i-ai creat

La prima intrare, atacatorul își creează adesea un cont de administrator direct în baza de date. Astfel, chiar dacă ștergi toate fișierele infectate, el se loghează liniștit ca admin și pune virusul la loc. Uneori contul are un nume care imită ceva legitim, alteori e ascuns complet din lista de utilizatori și apare doar dacă te uiți direct în baza de date. Companii de securitate precum Sucuri documentează frecvent backdoor-uri care fac exact asta: fabrică astfel de conturi admin ascunse, tocmai ca să te reinfecteze.

Taskuri cron malițioase (site-ul se reinfectează singur)

WordPress are un programator intern de sarcini, numit WP-Cron, care rulează acțiuni la intervale regulate (verifică actualizări, trimite emailuri programate și altele). Atacatorii adaugă acolo o sarcină proprie: la fiecare câteva ore, descarcă din nou virusul de pe un server străin și recreează fișierele pe care tocmai le-ai șters. Practic, site-ul se reinfectează singur, fără ca atacatorul să mai fie nevoit să facă ceva. Sucuri a documentat în detaliu acest tipar, inclusiv cazuri în care fișierul wp-cron.php recreează singur un plugin malițios la următoarea vizită, după ce l-ai șters. Dacă ai curățat tot, dar peste o zi fișierele reapar, un task cron ascuns e suspectul principal.

Cod injectat direct în baza de date

Nu tot virusul stă în fișiere. O parte se strecoară în baza de date, mai ales în tabelul wp_options, sau în conținutul articolelor și paginilor: redirecturi, scripturi care apar la vizitatori, instrucțiuni ascunse. Aici e și capcana clasică: oamenii reinstalează WordPress de la zero, cred că au rezolvat, dar reinstalarea atinge doar fișierele, nu și baza de date. Dacă userul ascuns, taskul cron sau codul injectat stau în baza de date, ele rămân intacte după reinstalare.

Mu-plugins și fișiere de configurare modificate

Există un folder special, mu-plugins (must-use plugins), ale cărui fișiere se încarcă automat la fiecare cerere, fără să apară în lista normală de pluginuri din panou. E o ascunzătoare ideală pentru cod care reface infecția. La fel, fișierele wp-config.php și .htaccess sunt deseori modificate ca să încarce cod străin sau să redirecteze traficul. Dacă te uiți doar prin panoul WordPress, nu le vezi niciodată.

Pluginuri și teme piratate (nulled)

Variantele „nulled" (piratate) de pluginuri și teme premium conțin aproape mereu cod ascuns și backdoor-uri, familia WP-VCD fiind cazul clasic. Cât timp tema sau pluginul piratat rămâne instalat, ai un izvor permanent de reinfectare chiar în site, în plus aceste variante nu primesc actualizări de securitate. Despre de ce sunt o cauză atât de frecventă am scris pe larg în ghidul despre curățarea unui site WordPress virusat.

Parola care nu s-a schimbat niciodată

Uneori nu e nimic lăsat în site. Pur și simplu atacatorul are în continuare parola: cea de la admin, de la găzduire, de la FTP sau a bazei de date. Dacă ai curățat fișierele dar nu ai schimbat parolele, sau le-ai schimbat în timp ce site-ul era încă infectat (caz în care le-a putut fura din nou), el se loghează la fel de simplu ca tine. Și mai des: aceeași parolă e refolosită în mai multe locuri, deci o scurgere de pe alt site îi dă acces și aici. Despre cum funcționează atacurile cu parole refolosite poți citi în articolul despre credential stuffing.

De ce „mai caut o dată cu pluginul de scanare" deseori nu ajunge

Pluginurile de scanare (Wordfence, Sucuri, MalCare) sunt utile și ar trebui rulate, dar au o limită care ține de natura lor: rulează din interiorul WordPress. Un backdoor care stă la nivel de server, în afara instalării WordPress, pur și simplu nu intră în raza lor. La fel, un fișier nou, complet necunoscut, poate să nu semene cu nimic din baza lor de semnături. De-aia un site care „a fost scanat și a ieșit curat" se reinfectează totuși: scanerul a verificat camera, dar cheia era sub preșul din curte.

Asta nu înseamnă că scanarea e inutilă, ci că o singură unealtă nu e de ajuns. O curățare de încredere combină scanarea automată cu o verificare manuală a locurilor pe care boții le ocolesc: baza de date, taskurile cron, folderul mu-plugins, conturile de utilizator, fișierele de configurare.

Cum oprești reinfectarea, în ordine

Mai jos e succesiunea care chiar funcționează. Important e ordinea: dacă schimbi parolele cât timp site-ul e încă infectat, le poate fura din nou; dacă restaurezi înainte să verifici baza de date, readuci problema. Parcurge pașii unul câte unul.

De ce doar o protecție la nivel de rețea oprește runda a doua

Pune-ți o întrebare cinstită: chiar dacă reușești o curățare perfectă, ce s-a schimbat la cauza inițială? Dacă boții au intrat printr-un plugin cu o vulnerabilitate, plugin-ul e tot acolo. Dacă au ghicit parola prin încercări repetate, nimic nu-i oprește să încerce din nou. Curățarea repară trecutul, dar nu schimbă viitorul. De-aia un site infectat o dată e atât de des infectat și a doua oară: poarta de intrare a rămas deschisă.

Diferența o face mutarea apărării în fața site-ului, la nivel de rețea, nu doar înăuntrul lui. Patru lucruri contează cel mai mult, iar împreună schimbă complet ecuația.

• Un WAF în față: un filtru care oprește traficul rău intenționat și tentativele de a reinjecta cod înainte ca acestea să ajungă la WordPress. Dacă vrei să înțelegi mai exact ce face, am explicat pe larg ce este un WAF.
• Actualizări la zi: majoritatea spargerilor folosesc vulnerabilități deja cunoscute, cu patch disponibil. Nucleul, temele și pluginurile actualizate închid exact ușile pe care intră boții automați.
• Autentificare în doi pași (2FA): chiar dacă o parolă e furată sau ghicită, contul nu mai poate fi accesat fără al doilea factor. E una dintre cele mai eficiente măsuri și se activează în câteva minute, vezi cum activezi 2FA.
• Un backup curat, testat și păstrat separat: ca să ai mereu o versiune sigură din care poți reporni, fără riscul de a readuce backdoor-ul.

Observă logica: WAF-ul oprește tentativa de reinjectare, actualizările închid breșa, 2FA blochează login-ul cu parolă furată, iar backupul curat îți garantează un punct de revenire sigur. Niciuna singură nu e suficientă, dar împreună transformă site-ul dintr-unul pe care îl tot cureți într-unul care rezistă. Pentru lista completă de măsuri, în ordinea impactului, vezi ghidul despre cum protejezi un site WordPress de atacuri.

Și avertismentul din Google? Nu pleacă singur

Dacă în timpul infecției Google a marcat site-ul cu eticheta „Acest site poate fi spart", reține că ea nu dispare automat după curățare. Trebuie să ceri o reexaminare din Google Search Console, la secțiunea „Probleme de securitate", și doar după ce ești sigur că tot site-ul (inclusiv baza de date) e curat. Google se așteaptă să explici concret problema, ce ai făcut ca s-o repari și rezultatul. O cerere depusă cât timp mai există un backdoor doar prelungește penalizarea, fiindcă reexaminarea poate dura de la câteva zile la câteva săptămâni. Tot procesul, pas cu pas, e în ghidul despre recuperarea unui site spart și penalizat în Google.

Pe scurt

Dacă site-ul se reinfectează la nesfârșit, nu e magie și nu e ghinion: undeva a rămas o cheie sub preș, un backdoor, un cont admin ascuns, un task cron, cod în baza de date sau pur și simplu o parolă care nu s-a schimbat. Curățarea care șterge doar efectele, fără să caute mecanismul de revenire și fără să închidă breșa de intrare, e o curățare pe jumătate. Adevărata rezolvare are două părți: cureți temeinic, inclusiv baza de date, și apoi muți apărarea în fața site-ului ca să nu mai reintre prin aceeași ușă.