Magazin online căzut cu pagină albă: 54 de zile de spam SEO în spate

Sesizarea a fost cât se poate de simplă: magazinul nu mai merge. Într-o dimineață de septembrie, vizitatorii care deschideau site-ul primeau o pagină complet albă — fără eroare, fără mesaj, fără nimic.

Pagina albă era însă ultimul simptom, nu primul. Investigația a arătat că accesul neautorizat pe server începuse cu 54 de zile înainte, pe 17 iulie 2026, iar în tot acest interval magazinul funcționase perfect. Nimeni nu avea de ce să bănuiască ceva.

Ce a găsit investigația

Pe site erau 28 de fișiere malițioase, aparținând la patru familii distincte de cod. Distincte e cuvântul important: nu erau variante ale aceluiași instrument, ci unelte cu autori și scopuri diferite, aflate simultan pe același server. Tiparul e consecvent cu un acces obținut o dată și revândut mai departe, sau exploatat în paralel de mai mulți.

• Un generator de spam SEO. Elementul cu impact comercial real. Producea mii de pagini false, de câte 542 KB fiecare, pe domeniul clientului — pagini pe care Google le accesa activ și le indexa. A generat, ca efect secundar, 493 MB de erori în jurnalele serverului.
• Un canal de comandă și control. Două fișiere ascunse în zona de administrare, care descărcau și rulau cod de pe un server extern, folosind 12 metode alternative de conectare pentru cazul în care una ar fi fost blocată. Practic, atacatorul putea schimba oricând ce face site-ul, fără să mai atingă vreun fișier.
• 19 puncte de acces de rezervă. Fișiere mici, de 740 de octeți, identice între ele, împrăștiate prin toate directoarele site-ului. Fiecare permitea rularea de comenzi pe server. Rolul lor era asigurarea: dacă erau găsite câteva, restul rămâneau funcționale.
• Trei module de administrare ascunse, între 2 KB și 92 KB, în directorul de fișiere încărcate. Unul se prezenta drept modul legitim de optimizare și avea parolă proprie de acces.

Cum a intrat

Cel mai vechi fișier malițios a apărut pe 17 iulie 2026, la 22:19, direct în directorul de încărcare al modulului de formulare — Super Forms 6.3.312:

wp-content/uploads/superforms/2026/07/cache_0nqiymee.php

Un fișier de 740 de octeți, aparent identic cu celelalte 18 din aceeași serie. Diferența e că are o amprentă criptografică distinctă de a lor, în timp ce restul sunt copii perfecte una a alteia. Este semnătura tipică a primei breșe: fișierul plasat manual, înainte ca atacatorul să își automatizeze replicarea, moment din care toate copiile devin identice.

De aici rezultă și vectorul cel mai probabil — un modul de formulare care accepta încărcarea unui fișier PHP în propriul director de upload. Nu putem însă transforma „cel mai probabil” în certitudine: jurnalele de acces web din iulie nu se mai păstrau la momentul investigației.

De ce a contat directorul de fișiere încărcate

Un fișier malițios ajuns pe server nu folosește nimănui dacă nu poate fi rulat. Aici putea.

Directorul wp-content/uploads/ nu avea nicio restricție care să împiedice execuția de cod. Este directorul în care ajung imaginile, documentele și atașamentele — deci exact directorul în care un site permite, prin definiție, ca cineva din exterior să scrie fișiere. Faptul că orice fișier ajuns acolo putea fi executat printr-o simplă cerere din browser transformă o încărcare de fișier într-o rulare de program.

Aceasta este cauza structurală a incidentului. Nu explică singură cum a fost păcălit modulul de formulare, dar explică de ce, odată strecurat un fișier, atacatorul a obținut control asupra serverului.

Două fișiere cu marcaje de timp falsificate

Cele două fișiere din zona de administrare — wp-admin/css/in.php și wp-admin/js/awx.php — aveau marcaje de timp care le dădeau vechi de peste un an. Într-o listare de director apăreau ca fișiere vechi, deci neinteresante: exact efectul urmărit.

Le-am putut infirma pentru că exista un punct de comparație. O arhivă de referință a site-ului, din decembrie 2025, nu conținea niciunul dintre cele două fișiere. Concluzia nu are nevoie de interpretare: dacă nu existau atunci, marcajul care spune că datează de dinainte e fals.

Merită reținut ca metodă, pentru că e ieftină și funcționează: o copie de siguranță veche nu e doar un mijloc de restaurare, ci și un martor. Fără arhiva din decembrie, cele două fișiere ar fi trecut drept componente legitime ale site-ului.

Ce nu am putut stabili

Nu am identificat exfiltrare de date, iar comportamentul observat este consecvent cu monetizarea prin spam SEO, nu cu furtul de informații: un atacator interesat de datele clienților nu are motive să genereze mii de pagini pentru Google și să atragă atenția asupra sa.

Asta nu înseamnă că putem exclude accesul la date. Atacatorul a avut, timp de 54 de zile, drept de citire pe toate fișierele site-ului — inclusiv pe fișierul de configurare care conține datele de conectare la baza de date. Nu avem dovezi că le-a folosit; nu putem dovedi nici că nu le-a folosit. În consecință am tratat parolele ca fiind compromise și am prezentat clientului distincția exact în această formă: e o ipoteză prudentă, nu o constatare.

Cronologia

17 iulie 2026, 22:19

Prima breșă. Un fișier malițios este încărcat în directorul de upload al modulului de formulare. Este singurul din serie cu o amprentă diferită de celelalte.

18 – 20 iulie 2026

Consolidarea accesului: încă 18 fișiere identice, copiate în directoare diferite ale site-ului, ca acces de rezervă.

3 septembrie 2026

Un fișier de sistem WordPress este înlocuit. Site-ul începe să genereze mii de pagini false pentru motoarele de căutare.

8 septembrie 2026

Două module de administrare ascunse, dintre care unul deghizat în modul legitim de optimizare, cu parolă proprie.

9 septembrie 2026, 02:20

Un modul instalat pe site descarcă și rulează cod de pe un server extern controlat de atacator.

9 septembrie 2026, 11:36

Fișierul principal al site-ului este suprascris cu 9 octeți. Magazinul cade — pagina albă.

9 septembrie 2026, 11:38

Începe investigația: identificarea fișierelor compromise și arhivarea probelor.

9 septembrie 2026, 11:53

Site-ul revine online. Fișierele de sistem sunt restaurate din sursa oficială WordPress.

9 septembrie 2026, 12:11

Verificările independente se încheie: scanare antimalware completă și control de integritate, fără detecții.

Curățarea, pas cu pas

Ordinea a fost aleasă deliberat — securizare înainte de ștergere, ștergere înainte de repunere online — și e partea care merită explicată, pentru că de ea a depins rezultatul:

• Arhivarea probelor. Cele 28 de fișiere, cu amprentele lor criptografice și cu jurnalele aferente, păstrate în afara zonei publice, pentru eventuale verificări ulterioare.
• Blocarea execuției de cod în directorul de fișiere încărcate — înainte de ștergere. Inversată, ordinea ar fi lăsat o fereastră în care atacatorul, încă având acces, ar fi putut reinstala ce tocmai ștergeam. Măsura a neutralizat pe loc 21 din cele 28 de fișiere: au rămas pe disc, dar au încetat să mai fie programe.
• Eliminarea codului malițios — toate cele 28 de fișiere, plus modulul temporar descărcat de pe serverul extern.
• Restaurarea fișierelor de sistem din sursa oficială WordPress 6.8.8, verificate criptografic înainte de instalare. Nu am copiat fișiere „curate” de altundeva; le-am luat de la sursă.
• Refacerea instrucțiunilor pentru motoarele de căutare. Fișierul care le indica paginile false fusese modificat.
• Eliberarea a 500 MB de spațiu ocupat de jurnalele de erori umflate de activitatea de spam.
• Regenerarea cheilor de securitate, care invalidează toate sesiunile active. Orice sesiune de administrare obținută de atacator a devenit inutilizabilă instantaneu.
• Amprentarea celor 27.265 de fișiere ale site-ului și instalarea unui mecanism de monitorizare: orice modificare neașteptată va fi vizibilă de acum înainte.

De ce curățare chirurgicală, nu reinstalare

Am eliminat exact fișierele malițioase identificate, fără să reinstalăm site-ul de la zero. E o decizie cu un cost — cere să știi ce cauți și să poți demonstra la final că nu ai ratat nimic — dar are un avantaj pe care reinstalarea nu îl are: conținutul, produsele, comenzile și configurările clientului au rămas neatinse. Pe un magazin care procesează comenzi zilnic, o reinstalare „de siguranță” mută problema din zona securității în zona pierderii de date.

Verificările de la final

O curățare e completă doar dacă poate fi demonstrată, iar fiecare verificare de mai jos folosește o metodă independentă de cea prin care am făcut curățarea:

• integritatea fișierelor de sistem WordPress, față de semnăturile oficiale — trece integral
• integritatea celor 20 de module instalate, față de semnăturile oficiale — zero modificări
• scanare antimalware independentă (Imunify360) pe 67.117 fișiere — 0 detecții
• baza de date — nemodificată: fără conturi noi, fără conținut injectat, fără opțiuni alterate
• conturile de administrare — ambele legitime, niciunul creat de atacator
• paginile publice — acasă, magazin, rezervări, autentificare: funcționale
• paginile de spam — inexistente, testat din perspectiva Googlebot, nu doar a unui vizitator obișnuit
• blocarea execuției de cod în directorul de fișiere încărcate — verificată printr-o cerere efectivă, nu doar prin prezența regulii

Ce i-am recomandat clientului

• Actualizarea modulului de formulare. Super Forms 6.3.312 este cel mai probabil punctul de intrare. La cererea clientului a rămas activ, pentru ca formularele de rezervare să funcționeze în continuare — riscul e compensat prin blocarea execuției de cod, dar actualizarea rămâne necesară. Necesită licența comercială aferentă modulului.
• Schimbarea parolelor — baza de date, cele două conturi de administrare ale site-ului și accesul la găzduire (cPanel/FTP). Fișierele de configurare au fost lizibile pentru atacator 54 de zile.
• Actualizarea magazinului online. WooCommerce rula versiunea 8.0.2, în timp ce versiunea curentă era 11.1.0 — trei versiuni majore diferență, pe un site care procesează comenzi. Recomandarea vine cu o condiție: testare prealabilă într-un mediu separat.
• Curățarea prezenței în Google. În Search Console: solicitarea eliminării paginilor false indexate, retrimiterea hărții reale a site-ului și verificarea secțiunii Security Issues. Fără acest pas, paginile de spam pot rămâne vizibile în rezultate încă săptămâni bune după ce site-ul e curat.
• Un ciclu lunar de actualizare și copii de siguranță externe automate. Site-ul avea module cu întârzieri mari de actualizare, oricare putând deveni al doilea punct de intrare. Iar arhiva care ne-a servit ca martor în această investigație data din decembrie 2025 — utilă, dar mult prea veche pentru a fi fost și o opțiune reală de restaurare.
• Semnalarea problemei către furnizorul de găzduire. Scanarea la nivel de server a arătat infecții active și pe alte conturi găzduite pe același server partajat.

Ce merită reținut

• Indisponibilitatea e adesea ultimul simptom, nu primul. Site-ul a „funcționat” impecabil 54 de zile, timp în care era deja controlat din exterior. Momentul în care ceva se strică nu e momentul în care a început problema — e doar momentul în care a devenit vizibilă.
• Blocarea execuției înainte de ștergere elimină fereastra de reinstalare. Cât timp atacatorul mai are acces, ștergerea fișierelor e o cursă pe care o poți pierde. Neutralizarea lor înainte schimbă ordinea în favoarea ta.
• Paguba de SEO supraviețuiește curățării. Fișierele se șterg într-o dimineață; miile de pagini false intrate în indexul Google se curăță separat, cu întârziere și cu efort din partea proprietarului. E cel mai bun argument pentru care un site compromis nu trebuie lăsat „să fie verificat săptămâna viitoare”.

Un caz cu aceeași monetizare prin spam SEO, dar cu alt vector de intrare, e descris în studiul de caz cu patru backdoor-uri pe un site corporate. Aceeași cauză structurală — un director care execută cod deși nu ar trebui — apare și în cazul webshell-ului reinstalat prin cron. Cum arată o intervenție de la un capăt la altul e descris pe pagina de curățare malware WordPress.

Anexă tehnică — indicatori de compromitere

Pentru administratorii de magazine WooCommerce și pentru colegii din industrie care vor să-și verifice propriile servere:

Generator de spam SEO

/saiga.php (14.580 octeți, 3 septembrie 2026) și /wp-blog-header.php (13.416 octeți, fișier de sistem înlocuit)

Fișierul care a doborât site-ul

/index.php redus la 9 octeți, 9 septembrie 2026 — un fișier de sistem golit, nu un fișier adăugat

Canal de comandă și control

/wp-admin/css/in.php (9.551 octeți) și /wp-admin/js/awx.php (7.149 octeți), ambele cu marcaje de timp falsificate; 12 metode alternative de conectare către serverul extern

Module de administrare ascunse

/wp-content/uploads/buy.php (92.570 octeți), /wp-content/uploads/ed_ncat5uf5.php (15.215 octeți) și /wp-content/uploads/ed_tujvo41v.php (2.425 octeți, deghizat în modul de optimizare, cu parolă proprie)

Prima breșă

wp-content/uploads/superforms/2026/07/cache_0nqiymee.php — 740 octeți, 17 iulie 2026, 22:19; amprentă diferită de restul seriei

Puncte de acces de rezervă

18 fișiere cache_*.php de câte 740 octeți, identice între ele, replicate în directoare diverse pe 19 – 20 iulie 2026

Modul descărcat de la distanță

/tmp/app_cache_x5FsPh — 8.176 octeți, 9 septembrie 2026

Infrastructura atacatorului

depozit public de cod, adresă dezactivată aici ca să nu fie accesată din greșeală: gitlab[.]com, contul workrepo645-ctrl

Cauză structurală

directorul wp-content/uploads/ fără restricție de execuție — orice fișier PHP ajuns acolo se executa printr-o cerere web

Verificare recomandată (execuție)

plasarea unui fișier PHP inofensiv în directorul de fișiere încărcate și cererea lui din browser — orice răspuns diferit de refuz înseamnă că directorul poate rula cod

Verificare recomandată (marcaje de timp)

compararea fișierelor cu o copie de siguranță mai veche: un fișier „vechi” care lipsește dintr-o arhivă anterioară are marcajul falsificat

Verificare recomandată (persistență)

căutarea fișierelor PHP mici, de dimensiune identică, repetate în directoare fără legătură între ele — tiparul clasic de acces de rezervă

Mediu

WordPress 6.8.8 · WooCommerce 8.0.2 · PHP 8.2 · găzduire partajată cPanel/LiteSpeed · 27.265 fișiere PHP · 67.117 fișiere totale