Reparare site spart: trei cazuri din ultimele luni

În ultimele luni am curățat trei site-uri WordPress sparte. Unul e un magazin online, altul site-ul de prezentare al unei firme, al treilea al unui furnizor de servicii medicale. Nu scriu numele clienților, dar scriu detaliile, pentru că repararea unui site spart înseamnă mult mai multă muncă decât se vede din afară, iar greșelile se repetă.

1. Magazin online: parolele furate ale unui colaborator extern

Ce s-a întâmplat: pe calculatorul specialistului extern în marketing care lucra cu magazinul, un malware a furat parolele salvate în browser. Printre ele erau parola de administrator a magazinului și parola găzduirii. Două zile mai târziu, atacatorul s-a autentificat.

În trei zile a făcut următoarele:

• cu editorul de teme încorporat în WordPress a scris o ușă din spate într-unul dintre fișierele temei
• cu un modul a dat drepturi de administrator la două conturi de client nefolosite de mult timp
• a înlocuit fișierul jQuery al WordPress cu un cod ofuscat de 1,2 MB, care rula la fiecare vizitator, inclusiv pe pagina de finalizare a comenzii
• la final a pus o pagină falsă de „verificare Cloudflare", care îi cerea vizitatorului să copieze și să ruleze o comandă pe propriul calculator

Jurnalele arătau că a consultat și lista utilizatorilor și a comenzilor, așa că totul a trebuit tratat ca incident de securitate a datelor. Conform GDPR, firma are în acest caz 72 de ore să decidă dacă notifică autoritatea (în România, ANSPDCP).

Ce am reparat: am descărcat din nou nucleul WordPress și l-am comparat fișier cu fișier cu sumele de control oficiale. Fișierului jQuery i-am dat un nou marcaj de versiune, pentru că browserele vizitatorilor ar fi putut încărca zile întregi copia infectată din cache. Am readus drepturile celor două conturi de client, am șters modulele atacatorului și contul colaboratorului extern, am deconectat pe toată lumea și am schimbat cheile secrete WordPress (salt). Am dezactivat editorul de fișiere încorporat. Fiecare administrator și manager de magazin a primit parolă nouă, iar autentificarea în doi pași a devenit obligatorie. Am schimbat și cheile serviciilor conectate la magazin (facturare, newsletter, trimitere de e-mailuri).

Lecția: colaboratorul extern a curățat și el în aceeași dimineață, dar a scos doar ușa din spate din temă și pagina falsă de verificare. jQuery-ul înlocuit și cei doi administratori noi au rămas. După o curățare parțială site-ul pare curat, iar atacatorul se poate întoarce oricând.

2. Site de firmă: malware ascuns ani de zile, vizibil doar pentru Google

Ce s-a întâmplat: pentru vizitatori, site-ul firmei arăta normal. Google, în schimb, vedea pe el spam de jocuri de noroc, o pagină de 17 MB cu cuvinte cheie în limbi străine. Asta se numește cloaking: malware-ul verifică cine cere pagina și îi dă robotului de căutare altceva decât unui om.

Când am început să reconstitui ce s-a întâmplat, am aflat următoarele:

• site-ul avea două copii pe două servere. Infecția fusese mutată odată cu site-ul pe noua găzduire, la o migrare anterioară.
• primele urme sunt din 2023. WordPress a fost reinstalat atunci, dar folderele vechi (aproape o mie de fișiere PHP) au rămas lângă el.
• din 2024, printr-un modul de fragmente de cod, în fiecare săptămână apărea un fragment nou în site. Acesta făcea redirecționarea și spamul.
• printre module erau 14 module false de galerie, cu nume aleatorii. Fiecare era o copie exactă a modulului oficial, plus un fișier care era ușa din spate. Unul încerca să citească jurnalul de e-mail, adică aduna parole de e-mail.
• în ianuarie 2026, cineva s-a autentificat de nouă ori cu singurul cont de administrator, de pe adrese IP străine diferite. Parola se scursese, deci.

Același nume de utilizator și aceeași parolă funcționau și pe site-ul soră al firmei. Acolo am găsit 17 fișiere infectate în rădăcina site-ului: încărcătoare, o pagină de phishing și descărcări de malware.

Ce am reparat: am salvat totul în afara serverului înainte să ating ceva. De pe site-ul soră am eliminat cele 17 fișiere. Pe site-ul infectat am oprit WordPress și am dezactivat rularea PHP în rădăcina site-ului, așa că acolo nu poate rula niciun cod până când site-ul nu e reconstruit curat.

Lecția: reinstalarea nu curăță nimic dacă fișierele vechi rămân pe server. Iar cloaking-ul nu îl observă niciodată proprietarul, pentru că el vede varianta pentru oameni. Se poate depista doar dacă cineva cere regulat pagina și cu ochii robotului de căutare.

3. Furnizor de servicii medicale: când curățarea nu mai e posibilă

Ce s-a întâmplat: malware-ul se răspândea la nivelul contului de găzduire și a infectat patru instalări WordPress din același cont. Și după două curățări s-a rescris singur în câteva minute.

Ce am făcut: aici am ales, în locul curățării, o reconstruire curată pe un server nou. De pe serverul vechi nu am mutat niciun fișier. Tema și modulele le-am reinstalat din surse oficiale, iar baza de date am filtrat-o manual.

În baza de date am găsit 20 de articole spam (cu linkuri afiliate cu conținut pentru adulți), pe numele unui utilizator necunoscut, create în masă în câteva minute. Scanarea de malware nu le-a prins, pentru că erau articole obișnuite. Între timp, antivirusul găzduirii a găsit alte foldere de module mascate, cu nume formate din marcaje de timp, și un wp-config.php fals.

Lecția: jurnalele găzduirii existau doar de la cinci zile după infectare, așa că punctul de intrare nu se va afla niciodată exact. Din experiența furnizorului de găzduire, cea mai frecventă cale este un modul neactualizat sau o temă premium piratată („nulled"). În unele dintre acestea se pune intenționat o ușă din spate.

Ce au în comun cele trei cazuri de site spart?

• În două dintre cazuri au intrat cu parola. Într-unul au furat-o din browserul unui colaborator extern, în celălalt aceeași parolă era folosită ani de zile pe două site-uri.
• Atacatorii au rămas mult timp înăuntru. Zile, luni, într-un caz ani, pentru că nimeni nu verifica regulat ce se schimbă pe site.
• Curățarea parțială nu ajunge. Repararea unui site spart înseamnă schimbarea parolelor, deconectarea sesiunilor, schimbarea cheilor secrete și eliminarea fiecărui fișier străin, inclusiv din baza de date. Uneori reconstruirea e calea mai rapidă.

Ce am introdus după aceste cazuri pe site-urile pe care le întrețin: fiecare colaborator primește cont propriu, doar cu drepturile necesare, și îl șterg la finalul lucrului. Pentru administratori, autentificarea în doi pași e obligatorie. Editorul de fișiere încorporat e dezactivat. În folderul de încărcări nu poate rula PHP.

Dacă site-ul tău l-a făcut altcineva și nu știi cine are acces la el, primul pas al preluării site-ului este tocmai inventarierea acestor accese. Iar dacă vezi deja semne suspecte, scrie-mi.