Malware WordPress: Cum detectați și eliminați infecțiile de pe site

Malware WordPress: Cum detectați și eliminați infecțiile de pe site este ghidul pe care îl aplicăm la fiecare site compromis care ajunge la noi, în medie două pe lună. Un site infectat redirecționează vizitatorii spre pagini de păcăleală, trimite spam, găzduiește pagini de farmacie sau de jocuri de noroc pentru Google, sau pur și simplu servește ca punct de plecare pentru atacuri asupra altora, ani de zile, fără ca proprietarul să observe. Cauzele sunt aproape întotdeauna aceleași: module și teme neactualizate sau „nulled”, parole slabe, permisiuni largi și site-uri vechi uitate pe același cont.

Ghidul urmează ordinea corectă: confirmare, izolare, copie pentru analiză, curățare prin reinstalare (nu prin „ștergere de fișiere suspecte”), baza de date, credențiale, prevenire, Google. Săritul peste un pas aduce reinfectarea în câteva zile, ceea ce am văzut la fiecare site „curățat” de altcineva înainte.

Malware WordPress: Cum detectați și eliminați infecțiile de pe site

Simptomele

• Redirecționări spre alte site-uri, deseori doar pentru vizitatorii de pe telefon sau doar pentru cei veniți din Google (camuflare).
• Pagini sau articole noi, în alte limbi, cu produse pe care nu le vindeți; apar în căutarea site:domeniu.ro.
• Avertisment de la Google în Search Console (Security issues) sau ecran roșu în browser.
• E-mailuri respinse, domeniul pe liste de spam, furnizorul care anunță trimiteri masive din cont.
• Consum de resurse brusc, procese PHP necunoscute, fișiere noi în dosare de încărcare.
• Utilizatori administratori pe care nu i-ați creat; module noi pe care nu le-ați instalat.
• Reclame sau ferestre pe care nu le-ați pus, text ascuns în subsol, legături spre site-uri străine.

Pasul 1: confirmarea și izolarea

Înainte de a schimba ceva, salvați dovezile: o copie completă a site-ului infectat (fișiere și bază de date), într-un dosar în afara serverului, cu data. Este copia din care aflați cum a intrat atacatorul și de care aveți nevoie dacă o parte din date se pierde la curățare. Apoi puneți site-ul în mentenanță (503, cu datele de contact vizibile) sau, dacă distribuie malware activ, restricționați accesul la adresa IP proprie din .htaccess. Un site care redirecționează vizitatorii nu rămâne public în timpul curățării.

Pasul 2: găsirea infecției

Verificarea integrității fișierelor

Cea mai rapidă și mai sigură verificare: compararea fișierelor cu originalele de pe wordpress.org. Din terminalul cPanel cu WP-CLI sau prin SSH:

cd ~/public_html
wp core verify-checksums
wp plugin verify-checksums --all
wp theme list --status=active

Orice fișier de nucleu sau de modul raportat ca modificat sau ca „nu ar trebui să existe” este suspect. Temele nu au sume de control publice, deci se verifică manual (functions.php este locul preferat al injecțiilor) sau se compară cu o copie proaspătă a temei descărcată de la producător.

Fișiere modificate recent și cod ascuns

find ~/public_html -type f \( -name "*.php" -o -name "*.js" -o -name ".htaccess" \) -mtime -14 -not -path "*/cache/*" | head -100
grep -rlE "base64_decode|eval\(|gzinflate|str_rot13|preg_replace\(.*/e|create_function|\\\$_(GET|POST|REQUEST)\[.\w+.\]\s*\(" ~/public_html --include="*.php" | head -50
find ~/public_html/wp-content/uploads -name "*.php"
find ~/public_html -name ".htaccess" -newer ~/public_html/wp-config.php

Prima comandă listează fișierele modificate în ultimele două săptămâni (ajustați după data simptomelor). A doua caută funcțiile tipice ale codului ascuns; unele module legitime le folosesc, deci verificați contextul. A treia caută fișiere PHP în dosarul de încărcări, unde nu au ce căuta niciodată. A patra găsește fișiere .htaccess modificate după configurare, locul obișnuit al redirecționărilor rău intenționate.

Scanere

Wordfence (modul) compară fișierele cu depozitul WordPress și caută semnături cunoscute; util, dar rulează în interiorul site-ului infectat, deci poate fi păcălit. WPScan din exterior enumeră modulele vulnerabile și utilizatorii, cum arătăm în ghidul despre WPScan și Nikto. Scanerul furnizorului (Imunify, ClamAV) prinde ce cunoaște. Niciunul nu înlocuiește verificarea sumelor de control și căutarea manuală; le folosim pe toate, ca liste de candidați.

Pasul 3: curățarea prin reinstalare

Nu „curățați” fișiere PHP infectate rând cu rând; înlocuiți-le. Ordinea:

1. Nucleul: wp core download --force --skip-content înlocuiește wp-admin, wp-includes și fișierele din rădăcină cu originalele, păstrând wp-content și wp-config.php.
2. Modulele: ștergeți dosarul fiecărui modul și reinstalați-l din depozit (wp plugin install nume --force). Modulele plătite, din arhiva originală de la producător. Modulele pe care nu le mai folosiți: ștergeți, nu dezactivați.
3. Temele: la fel; păstrați doar tema activă și tema-copil, verificate manual, plus una implicită.
4. wp-config.php: comparați cu wp-config-sample.php; scoateți orice rând pe care nu îl recunoașteți, mai ales include-uri spre fișiere din uploads.
5. .htaccess: rescrieți-l de la zero, cu regulile standard WordPress și cele ale dumneavoastră.
6. uploads: ștergeți orice fișier PHP, HTML sau JavaScript; verificați și fișierele cu extensie de imagine, dar conținut PHP (comanda file arată tipul real).
7. Restul dosarului personal: dosare vechi (site-vechi, backup, test) sunt de obicei poarta de intrare; ștergeți-le sau scoateți-le din web.

wp core download --force --skip-content
wp plugin list --field=name | xargs -n1 -I{} wp plugin install {} --force
find ~/public_html/wp-content/uploads -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.html" \) -delete
find ~/public_html/wp-content/uploads -type f -name "*.jpg" -exec sh -c 'file "$1" | grep -q PHP && echo "$1"' _ {} \;

Pasul 4: baza de date

Infecțiile moderne stau și în baza de date: scripturi injectate în articole (wp_posts), în opțiuni (wp_options, mai ales siteurl, home și opțiunile temei), utilizatori administratori noi (wp_users) și module „ascunse” în tabela de opțiuni. Verificați:

wp user list --role=administrator
wp option get siteurl && wp option get home
wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%' OR post_content LIKE '%eval(%' LIMIT 50"
wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%' OR option_value LIKE '%base64_%'"

Ștergeți administratorii necunoscuți, curățați scripturile din conținut (cu atenție la scripturile legitime încorporate, de exemplu hărți) și verificați opțiunile temei și ale modulelor de cod personalizat, unde atacatorii pun cod care supraviețuiește reinstalării fișierelor.

Pasul 5: credențialele

Toate, în aceeași zi: parolele tuturor utilizatorilor WordPress (wp user update --user_pass sau forțarea resetării), cheile de securitate din wp-config.php (regenerate de pe api.wordpress.org/secret-key), parola bazei de date (și actualizarea ei în wp-config.php), parola cPanel, parolele FTP și de e-mail, tokenurile API ale modulelor. Sesiunile existente se invalidează odată cu cheile. Dacă parola cPanel a fost folosită și în altă parte, schimbați-o și acolo; furtul de parole din calculatorul administratorului este o cauză frecventă pe care curățarea site-ului nu o rezolvă.

Pasul 6: cum a intrat

Jurnalul de acces al serverului, filtrat după cererile POST spre fișiere PHP din zilele de dinaintea simptomelor, arată de obicei fișierul prin care a intrat atacatorul și adresa IP; metoda este în ghidul despre jurnalele de acces din cPanel. Cauzele pe care le găsim: un modul cu vulnerabilitate publicată, neactualizat (cel mai des), o parolă de administrator ghicită, un formular de încărcare fără validare, un site vechi de pe același cont. Fără această verificare, curățarea este temporară.

Pasul 7: prevenirea

• Actualizări în aceeași săptămână cu publicarea, pentru nucleu, teme și module; procedura este în ghidul despre actualizarea WordPress, a temelor și a modulelor.
• Autentificare în doi pași pentru toți administratorii, după ghidul despre autentificarea în doi pași, și protecția paginii de autentificare.
• Permisiuni 755 pe dosare și 644 pe fișiere, 600 pe wp-config.php; blocarea execuției PHP în uploads printr-un .htaccess dedicat.
• Fără module și teme „nulled”; fără site-uri vechi pe același cont.
• Copii de siguranță automate, în alt loc, testate, după ghidul despre copiile de siguranță automate pentru WordPress.
• Un firewall de aplicație (ModSecurity din cPanel sau cel al modulului de securitate) și limitarea încercărilor de autentificare.
• O verificare lunară cu wp core verify-checksums și wp plugin verify-checksums, din cron, cu rezultatul pe e-mail.

Lista completă a măsurilor este în ghidul despre securizarea unui site WordPress.

Pasul 8: Google și reputația

Dacă Search Console a raportat probleme de securitate, după curățare cereți revizuirea din raportul Security issues, cu o descriere scurtă a ce ați făcut. Google reverifică în câteva zile și scoate avertismentul. Verificați apoi raportul de indexare pentru paginile străine create de atacator: după ștergere dau 404 și ies din index singure, iar pentru cele multe, o cerere de eliminare temporară grăbește dispariția din rezultate. Verificați și listele de spam pentru e-mail dacă domeniul a trimis spam; scoaterea se cere la fiecare listă separat. Pașii de comunicare cu clienții și cu autoritatea de protecție a datelor, când au fost expuse date personale, sunt în ghidul despre răspunsul la incidente de securitate.

Când reinstalați totul de la zero

Dacă nu puteți stabili data infecției, dacă serverul întreg (nu doar contul) arată semne de compromitere, sau dacă site-ul a fost „curățat” de două ori și s-a reinfectat, restaurați dintr-o copie de dinaintea infecției pe un cont nou, actualizați totul înainte de a-l face public și migrați doar conținutul (articole, imagini, comenzi) din site-ul infectat, după verificare. Costă o zi; a treia curățare costă mai mult.

Surse

• Documentația WordPress, securizarea WordPress: permisiuni, chei, măsurile de întărire recomandate oficial.
• Ajutor Search Console, raportul Probleme de securitate: tipurile de probleme raportate și cererea de revizuire.