Parola era corectă din prima încercare

O instituție publică din România administra două site-uri WordPress în același cont de găzduire. La o analiză de securitate am descoperit că ambele erau compromise: un atacator avea acces de administrator încă din 29 iunie și, pe 6 august, injectase în site cod malițios livrat tuturor vizitatorilor.

Cauza nu a fost o vulnerabilitate a site-ului. A fost o parolă corectă, aflată în posesia altcuiva.

Parola era corectă din prima încercare

Un cont de administrator fusese folosit pentru autentificări reușite de pe aproximativ 35 de adrese IP diferite, toate din centre de date și rețele VPN din afara țării. Prima, pe 29 iunie; ultima, pe 6 august.

Detaliul care schimbă complet diagnosticul: erau autentificări reușite din prima încercare, nu tentative de ghicire. Atacatorul cunoștea parola înainte de a se conecta.

În paralel, site-ul era ținta a 3.944 de încercări automate de spargere a parolelor prin interfața xmlrpc.php, cu vârf între 24 și 26 iulie. Acelea nu au reușit niciodată — și tocmai contrastul dintre cele două tipare a confirmat că parola nu fusese spartă pe site.

Explicațiile probabile sunt două, ambele în afara serverului: un program de tip „infostealer" pe calculatorul personal al utilizatorului, sau reutilizarea aceleiași parole pe un alt serviciu care a suferit o breșă de date. Consecința practică este importantă pentru orice organizație: o parte din suprafața de atac a unui site nu se află pe site.

Cronologia

29 iunie

Prima autentificare reușită pe contul de administrator, de pe un IP străin.

20 iulie, 13:52

Atacatorul dezactivează pluginurile de securitate — inclusiv pe cel care limita încercările de autentificare — ca să-și ascundă urmele.

22–29 iulie

Instalează și folosește un plugin de management de fișiere pentru a încărca scripturi de control pe server.

29 și 31 iulie

Instalează două pluginuri false, deghizate în instrumente de monitorizare a traficului, pe ambele site-uri.

6 august, 07:07

Injectează codul malițios în tema site-ului principal.

6 august, 14:15

Ultima activitate observată.

8 august, 08:21

Codul malițios este eliminat. Fereastră de expunere publică: aproximativ 49 de ore.

Unde era ascuns codul — și de ce ajungea la vizitatori

Codul fusese adăugat într-un fișier JavaScript din nucleul temei, pe o cale care sugera un script de administrare. La prima vedere, un fișier care nu ar trebui să ajungă niciodată la un vizitator obișnuit.

În realitate, tema îl înregistra sub un alt nume și îl livra pe frontend. Injecția ajungea deci la absolut toți vizitatorii site-ului. Este exact genul de detaliu care face diferența între „am verificat fișierele temei" și „am verificat ce se încarcă efectiv în pagină".

Codul era un încărcător ascuns, scris astfel încât să nu poată fi recunoscut de scanerele obișnuite, și funcționa în doi pași:

1. interoga blockchain-ul public Polygon pentru a afla adresa curentă a serverului de comandă al atacatorului — tehnica numită EtherHiding, care îi permite să schimbe oricând destinația fără a mai atinge site-ul;
2. descărca de la acea adresă un script și îl rula în browserul fiecărui vizitator, prin new Function().

Conținutul livrat vizitatorilor era, prin urmare, la latitudinea atacatorului și putea fi schimbat în orice moment. În campaniile de acest tip, scriptul afișează de regulă false notificări de actualizare a browserului, redirecționări către site-uri frauduloase sau tentative de fraudă financiară.

Când logurile de securitate se opresc brusc, verifică întâi pluginul

Jurnalul de autentificări al pluginului de securitate se oprea brusc la 20 iulie, ora 13:52. Interpretarea comodă ar fi fost că atacul a încetat atunci.

Realitatea era inversă: atacatorul dezactivase pluginul chiar în acea sesiune. Tăcerea din jurnale nu era liniște, era rezultatul unei acțiuni deliberate — iar activitatea a continuat încă 17 zile, complet neînregistrată.

Este cea mai transferabilă lecție de investigație din acest caz: când jurnalele unui instrument de securitate se opresc brusc, prima verificare trebuie să fie starea instrumentului însuși, nu concluzia că nu mai are ce înregistra.

Al doilea site: un backdoor întreținut din 2022

Independent de incidentul de mai sus, pe al doilea site am găsit un set de pluginuri și teme false prezente din noiembrie 2022, inclusiv un program de acces la distanță de 143 KB, criptat AES-256-CBC.

Ce l-a făcut interesant: fișierele fuseseră golite în mod repetat de antivirusul serverului — dar erau rescrise periodic, cel mai recent în iunie 2026. Nu era cod rămas în urmă de la o infecție veche, ci o cale de acces întreținută activ timp de aproape patru ani. Antivirusul o dezactiva, atacatorul o repunea la loc, și nimeni nu s-a uitat vreodată la ciclu ca la un întreg.

Curățarea, pas cu pas

Copiile fișierelor malițioase au fost păstrate pentru analiză, în afara directorului web. Apoi:

1. am eliminat codul injectat din temă și am verificat că fișierul a revenit exact la forma sa originală;
2. am golit toate memoriile cache — 35 MB care încă livrau versiunea infectată vizitatorilor;
3. am șters cele două pluginuri false de pe ambele site-uri;
4. am eliminat programul de acces la distanță din 2022, împreună cu cele patru pluginuri și două teme false asociate;
5. am curățat referințele rămase în baza de date și reziduurile pluginului de management de fișiere;
6. am schimbat parolele tuturor celor 7 conturi de administrator, cu parole generate aleatoriu;
7. am rotit cheile de securitate ale ambelor site-uri — pasul care invalidează instantaneu toate sesiunile active, inclusiv eventualele cookie-uri de autentificare furate;
8. am reactivat pluginurile de securitate dezactivate de atacator pe 20 iulie.

Ambele site-uri au funcționat normal pe tot parcursul intervenției — nicio secundă de întrerupere.

Securizarea

• Blocarea interfeței xmlrpc.php, ținta celor 3.944 de tentative de spargere a parolelor.
• Interzicerea execuției de cod în directorul de fișiere încărcate al celui de-al doilea site.
• Corectarea permisiunilor fișierului de configurare, care era accesibil oricui pe același server.
• Eliminarea fișierelor care expuneau public versiunea exactă a platformei.

Verificările de la final

• 3.945 de fișiere WordPress comparate cu semnăturile oficiale, pe ambele site-uri — 0 alterate, 0 străine
• 0 conturi create de atacator; toți cei 7 utilizatori sunt legitimi și vechi
• 0 injecții în articole, pagini sau setări
• 0 sarcini programate malițioase
• 0 rezultate la căutarea finală de cod malițios pe întregul cont de găzduire
• 0 sesiuni active ale atacatorului

Ce a rămas în sarcina clientului

Trei dintre măsuri nu puteau fi făcute de noi — și fără ele problema se putea repeta:

• Verificarea calculatorului utilizatorului al cărui cont a fost folosit. Prioritatea numărul unu. Dacă acel calculator este în continuare infectat cu un program de furt de parole, parola nouă va fi furată la fel de repede ca cea veche. Am recomandat o scanare completă cu un antivirus actualizat și, în caz de confirmare, schimbarea tuturor parolelor introduse pe acel calculator.
• Distribuirea parolelor noi printr-un canal sigur — personal, telefonic sau printr-un manager de parole, nu prin e-mail simplu. Cu o regulă fermă: fiecare parolă folosită exclusiv pentru acest site. Reutilizarea este exact mecanismul care duce la incidente de acest tip.
• Activarea autentificării în doi pași. Este singura măsură care ar fi împiedicat complet acest incident: chiar cunoscând parola, atacatorul nu ar fi putut intra. Pluginul necesar era deja instalat pe site — trebuia doar activat și configurat.

Recomandări suplimentare, fără urgență: reducerea numărului de administratori (site-ul principal avea 5 conturi cu drepturi depline, deși unele doar publicau articole și puteau fi „Editor"), arhivarea în afara serverului web a două directoare vechi rămase în cont, verificarea adreselor de e-mail implicate pe haveibeenpwned.com, și monitorizarea autentificărilor timp de 7 zile — dacă apare o conectare suspectă după rotația parolelor, problema este pe calculatorul unui utilizator, nu pe server.

Nu era un atac țintit

Acesta a fost al treilea site pe care l-am curățat de aceeași campanie în intervalul 5–8 august. Un altul, cu aceeași familie de malware dar cu o cale de intrare complet diferită, e descris în studiul de caz despre cele 930.000 de încercări de parolă. Unul dintre pluginurile false apare identic în ambele cazuri.

Nu era un atac îndreptat împotriva acestei organizații, ci o campanie automată de amploare care exploatează parole de administrator obținute din diverse surse. Menționăm asta pentru că explică de ce măsura cea mai importantă nu este una tehnică la nivel de site, ci igiena parolelor și autentificarea în doi pași.

Anexă tehnică — indicatori de compromitere

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

Familie malware

EtherHiding (C2 prin blockchain Polygon)

Contract Polygon

0xbb9b2df9DCBd487212052DA0974d1A2E388322B0

Selector metodă

0xb68d1809

Identificator site atribuit de atacator

355d983b483b7b665fd8efd21f72082436aeea2d6b19a437

Model de încărcare

<domeniu-C2>/api.php?s=<id>&_v=<timestamp>

Ofuscare

XOR cu cheie de 16 octeți + Base64, executat prin new Function()

Artefacte eliminate

xadvanced-traffic-monitor-jveke (ambele instalări) · xpro-traffic-monitor-xzlss (ambele instalări) · framework-triappment (backdoor 143 KB, AES-256-CBC, pe al doilea site) · laravel-janet · metainteger-polydatum · platformist-quadendpointer · temele livealimentarium și consumptionphagocyte · reziduuri elFinder .tmb/ cu permisiuni 777 · wp-file-manager-pro în directorul de încărcări

Game de IP ale atacatorului

45.3.x · 65.111.x · 104.207.x · 209.50.x · 216.26.x — aproximativ 35 de adrese distincte, toate din centre de date

Reziduuri fără impact de securitate

tabelele wp_wpfm_backup (ambele baze de date), goale — pot fi șterse

Două măsuri pe care am ales să nu le aplicăm, și de ce: blocarea la nivel de firewall a gamelor de IP ale atacatorului — sunt intervale largi, cu risc real de a bloca vizitatori legitimi, iar după rotația parolelor și a cheilor valoarea măsurii este redusă; și interzicerea execuției PHP pe întregul director de conținut al celui de-al doilea site — există pluginuri care accesează direct fișiere PHP, iar restricția pe directorul de încărcări acoperă deja riscul real.