Compromis de trei ori în 18 luni — și nimeni nu a observat nimic

Site-ul de prezentare al unei companii de servicii din România funcționa aparent normal: paginile se încărcau, administratorii lucrau în panou fără să observe nimic ciudat. Analiza noastră a arătat altceva: site-ul fusese compromis de cel puțin trei ori, în ianuarie 2025, iunie 2025 și iulie 2026, iar în momentul verificării atacatorii aveau un cont de administrator ascuns, puteau executa cod pe server fără nicio parolă și foloseau domeniul pentru spam în motoarele de căutare.

Simptomul pe care nu-l vedea nimeni

Cel mai insidios element nu era vizibil pentru nimeni din companie: spam SEO. Unul dintre implanturi rescria titlurile și conținutul paginilor în pagini de keygen/warez/farma — dar doar pentru roboții motoarelor de căutare. Administratorii și vizitatorii normali vedeau site-ul obișnuit; Google vedea un site de piraterie.

Ca spamul să fie regenerat la fiecare cerere și să nu rămână „înghețat" în cache, malware-ul dezactiva forțat plugin-urile de cache (WP Rocket, W3TC, WP Super Cache). Alt implant injecta în plus ~113 KB de JavaScript ofuscat în fiecare pagină — servit doar vizitatorilor nelogați și suprimat pe pagina de login, exact ca un administrator care își verifică propriul site să nu vadă niciodată nimic anormal.

Reputația domeniului în Google era, cu alte cuvinte, sabotată în tăcere, fără ca cineva să aibă vreun motiv să bănuiască ceva.

Patru backdoor-uri, patru roluri

Implantul din mu-plugins — privilegii maxime

Directorul mu-plugins („must-use plugins") e special în WordPress: tot ce se află acolo se încarcă la fiecare cerere, înaintea plugin-urilor normale, și nu poate fi dezactivat din panoul de administrare. Fișierul index.php legitim din acest director are 28 de octeți și e gol. Acesta avea 121 KB. El crea contul de administrator ascuns și injecta JavaScript-ul ofuscat.

hero-slider-lite — copia de rezervă

Un plugin fals, prezentat ca „Hero Slider Lite" de la „Maple Digital" — nu există așa ceva în directorul oficial WordPress. Conținea exact același implant, iar cele două copii erau coordonate: dacă ștergeai una, cealaltă recrea contul de administrator la următoarea încărcare a site-ului. Acesta e motivul pentru care curățările parțiale, făcute de scanere automate, eșuează frecvent la astfel de infecții.

parrot-git-rss — execuție de cod la distanță

Cel mai direct instrument de acces. Adăugarea unui parametru secret la orice adresă a site-ului autentifica vizitatorul instantaneu ca administrator — fără utilizator, fără parolă. În plus, expunea un interpretor de comenzi PHP accesibil fără autentificare, cu traficul criptat AES ca să fie ilizibil pentru sistemele de monitorizare. Se ascundea singur din lista de plugin-uri, deci nu apărea nici la o inspecție vizuală atentă.

wordfence.php fals — deghizat în plugin de securitate

Un singur fișier de 27 KB, plasat direct în directorul de plugin-uri, cu numele celui mai cunoscut plugin de securitate WordPress — fără nicio legătură cu el. Era cel mai sofisticat dintre cele patru: primea comenzi prin înregistrări DNS de tip TXT, semnate criptografic cu o cheie RSA încorporată. Comunicarea prin DNS e aleasă tocmai pentru că trece de majoritatea firewall-urilor, care nu inspectează acest tip de trafic. Setul de comenzi includea execuție pe server, export al bazei de date, ștergere de fișiere și actualizarea propriului cod. Tot el genera spamul SEO.

Contul de administrator invizibil

În baza de date exista utilizatorul sys_maint (adresă sys@localhost.local, creat pe 23 iulie 2026, ora 18:12), cu rol de administrator. Implanturile interceptau interogările de utilizatori, astfel încât contul nu apărea nici în pagina Utilizatori, nici în API — exista, avea drepturi depline, dar era invizibil. Nu avea niciun articol sau comentariu asociat: exista exclusiv pentru acces.

Cum au intrat

Nu s-a putut stabili cu certitudine: log-urile serverului începeau abia cu o zi înainte de analiză, după toate cele trei infecții. E una dintre lecțiile cazului — fără log-uri păstrate pe termen lung, ancheta rămâne fără probe. Circumstanțial, indiciile arătau spre:

• plugin-ul wp-file-manager versiunea 8.0.4 — istoric bine documentat de vulnerabilități critice exploatate automat, în masă; lăsase în rădăcina site-ului un director cu permisiuni de scriere pentru oricine;
• fișierul wp-config.php cu permisiuni 0666 (citibil și scriibil de orice utilizator de pe server), terminat cu ~140 de linii goale — semnătura tipică a unui cod injectat șters ulterior de un tool automat. Adică site-ul mai fusese „curățat" înainte, parțial.

Ce era curat — verificat, nu presupus

La fel de important e ce nu era infectat, pentru că restrânge amploarea incidentului: nucleul WordPress (fiecare fișier comparat cu sumele de control oficiale — toate intacte), tema, folderul de încărcări, sarcinile programate, crontab-urile de sistem și cheile SSH. Compromiterea nu depășise aplicația web, iar celelalte site-uri de pe același cont de găzduire erau neafectate.

Curățarea, pas cu pas

1. Backup complet (fișiere + bază de date), verificat de integritate, înainte de orice modificare.
2. Carantină, nu ștergere: cele patru backdoor-uri au fost mutate în afara zonei web, blocate la permisiuni 000, cu amprentele SHA-256 înregistrate — rămân probe pentru furnizorul de hosting.
3. Curățarea bazei de date: contul sys_maint, cele 15 înregistrări asociate și markerii de ascundere — șterse; toate verificările post-ștergere au returnat 0.
4. Lista de plugin-uri active, reparată corect: redusă de la 28 la 25 de intrări. Detaliu tehnic: lista e stocată serializat, cu prefixe de lungime — o editare directă cu sed ar fi corupt-o și WordPress ar fi dezactivat în tăcere toate plugin-urile. Am folosit un script care deserializează, filtrează și verifică rezultatul.
5. Permisiuni normalizate: wp-config.php de la 0666 la 0640, directorul world-writable eliminat, wp-file-manager retras în carantină; la final, zero fișiere cu drept de scriere pentru „toată lumea".
6. Rotația celor 8 chei de sesiune din configurație — toate sesiunile active, inclusiv ale atacatorului, au fost invalidate pe loc.

Site-ul a rămas funcțional pe tot parcursul intervenției — nicio secundă de întrerupere.

Verificările de la final

• 0 rezultate la căutarea semnăturilor implanturilor pe tot contul de găzduire
• directorul mu-plugins — gol; rădăcina plugins/ — doar fișierul legitim
• 0 apariții de JavaScript injectat în paginile live
• ocolirea autentificării, testată direct — inactivă
• site și pagină de autentificare funcționale (HTTP 200)

Re-verificarea, după 6 zile

Nu am considerat cazul închis la predarea raportului. La 6 zile după intervenție am re-rulat toate verificările pe site-ul live: nicio reinfectare, carantina și backup-urile intacte, niciun fișier PHP nou suspect. Singurele modificări erau actualizări legitime de plugin-uri.

Ce i-am recomandat clientului

• Schimbarea urgentă a parolei bazei de date și a parolelor de administrator. Toate cele patru backdoor-uri puteau citi configurația site-ului, iar unul avea comandă dedicată de export al bazei de date — parolele trebuie considerate compromise. Curățarea închide ușile din spate; ușa din față rămâne deschisă până la schimbarea parolelor.
• Migrarea de pe PHP 7.2 — versiune ieșită din suport în 2020, fără patch-uri de securitate de aproape șase ani: un risc permanent, independent de incident.
• wp-file-manager rămâne în carantină. E principalul suspect ca vector de intrare; pentru transfer de fișiere există SFTP.
• Păstrarea log-urilor pe termen lung — imposibilitatea de a determina cum au intrat atacatorii s-a datorat exclusiv log-urilor prea scurte.
• Actualizarea promptă a componentelor vechi livrate cu tema (de exemplu revslider, js_composer), care nu se actualizează automat.

Anexă tehnică — indicatori de compromitere

Pentru administratorii și colegii din industrie care vor să-și verifice propriile site-uri:

Cont neautorizat

sys_maint / sys@localhost.local (creat 23.07.2026 18:12, ascuns din interfață prin pre_user_query / rest_user_query)

Șiruri de căutat în fișiere PHP

WP_IP_LOGIN · WP_IP_HOOKS · _wp_ip_ensure · _wp_ip (wp_usermeta) · _wp_ip_id (wp_options) · _PLN_SOME_KEY_ · _PLN_SOME_URL · _pln_get_some_dmn · parrot-git-rss · „colonel" (fragment din user-agent-ul de activare) · _0x (prefixul JS-ului ofuscat)

SHA-256 implant mu-plugins (121.407 octeți)

02c1ad9e0d31df7a71427a62a7b74e96227add66b4a2bd33bf0dbfd3bd3cc1e7

SHA-256 wordfence.php fals (27.933 octeți)

c55f7938fdcffb6217e14942bd55eb75e960fd796b50289301807347d2e67f82

SHA-256 hero-slider-lite.php

d48e5ab566f5ca69d976a869b7731ca1dd7c385a4193cfda33008ce8defd1b89

SHA-256 parrot-git-rss.php

2c8687060a11eddca8781727328a524cf9f13f4b3ed251b8719d0fc901e4d5db