930.000 de încercări de parolă și nicio alertă

O instituție publică din România ne-a solicitat o verificare de securitate după ce a suspectat o problemă pe site-ul propriu. Am găsit un atacator care avea acces de administrator de aproximativ 40 de zile și care injectase, în fiecare articol publicat, un script ce rula în browserul fiecărui vizitator.

Ce face acest caz instructiv nu este malware-ul în sine, ci cât de banală a fost calea de intrare — și cât de complet a lipsit orice semnal de alarmă.

Cum a intrat: nimic nu limita încercările de autentificare

Cauza nu a fost o vulnerabilitate exotică, ci absența oricărei limitări la autentificare. Serverul înregistrase aproximativ 930.000 de încercări eșuate de autentificare — 163 MB de jurnale — asupra celor patru conturi existente. Nicio măsură nu limita numărul de încercări.

Numele de utilizator nu trebuiseră ghicite: WordPress le expunea public prin paginile de autor, o slăbiciune standard rămasă nesecurizată. Atacatorul avea deci lista de conturi și un număr nelimitat de încercări. Unul dintre conturi a cedat.

Detaliul care doare: un plugin de securitate era deja instalat pe site, dar alertele lui erau dezactivate. Aproape un milion de încercări de spargere a parolelor au trecut fără ca nimeni să primească vreo notificare.

După ce a obținut parola, atacatorul s-a autentificat de 75 de adrese IP diferite, prin rețele de servere proxy, în 97 de sesiuni reușite.

Cronologia

29 iunie, 16:49

Prima autentificare reușită a atacatorului pe contul de administrator.

5 iulie, 13:32–13:46

Toate cele 10 articole publicate sunt modificate automat, unul la aproximativ un minut și 45 de secunde.

6 august, 07:11

O curățare parțială anterioară elimină codul vizibil — dar nu schimbă parolele.

6 august, 08:06

Atacatorul se autentifică din nou, la mai puțin de o oră după curățare. Accesul îi rămăsese valabil.

8 august

Investigație completă, eliminare, securizare.

Revenirea din 6 august este lecția centrală a acestui caz: o curățare care nu invalidează accesul atacatorului nu este o curățare. Ștergerea codului tratează simptomul; câtă vreme parola compromisă rămâne valabilă, atacatorul se întoarce pur și simplu pe ușa din față.

Fișierele erau curate. Infecția era în baza de date.

Am comparat fiecare fișier din instalare cu semnăturile oficiale publicate de WordPress.org: potrivire 100%, niciun fișier adăugat, niciun backdoor pe server. Un scanner clasic de fișiere ar fi ieșit curat.

Infecția era exclusiv în baza de date — scriptul fusese inserat la finalul textului fiecărui articol, invizibil pentru cititor și fără să modifice aspectul paginii.

Concluzia, valabilă pentru orice site: un scan de fișiere care iese curat nu înseamnă un site curat. Aici este și partea bună a poveștii — atacul s-a produs prin folosirea normală a unui cont furat, nu prin spargerea serverului.

De ce codul nu putea fi blocat prin firewall

Scriptul injectat făcea parte din familia EtherHiding. În loc să contacteze direct un server al atacatorului — care ar fi putut fi blocat — citea adresa serverului dintr-un contract publicat pe blockchain-ul Polygon.

Consecința practică: atacatorul poate schimba destinația oricând, fără să mai atingă site-ul, iar blocarea unui domeniu nu are niciun efect. Abia după ce obținea adresa, scriptul încărca în browserul vizitatorului codul final, al cărui conținut se putea schimba de la o oră la alta — redirecționări către pagini frauduloase, false alerte de actualizare care instalează programe malițioase, sau publicitate ascunsă.

Aceeași familie de malware a apărut, în aceeași săptămână, și pe alte site-uri pe care le-am curățat — cu o cale de intrare complet diferită. Detaliile, în studiul de caz despre parola furată.

Nu se poate stabili retroactiv ce anume a fost livrat vizitatorilor în cele aproximativ 34 de zile de expunere, pentru că acel conținut era controlat de la distanță și nu se păstrează nicăieri. Am spus asta clientului direct, în loc să oferim o falsă liniște.

Curățarea, pas cu pas

Toate dovezile au fost arhivate înainte de orice modificare, într-o locație inaccesibilă din internet: copie a bazei de date, jurnalele de autentificare, codul malițios în formă originală și decodată, lista celor 75 de adrese IP. Apoi:

1. am eliminat scriptul din toate cele 20 de înregistrări afectate din baza de date (articole și revizii);
2. am golit memoria cache — cinci pagini salvate încă serveau codul, independent de baza de date;
3. am șters trei directoare de module rămase în urma atacurilor;
4. am invalidat toate sesiunile active, inclusiv cele 10 sesiuni deschise ale atacatorului;
5. am resetat parolele tuturor conturilor de administrator;
6. am regenerat integral cheile criptografice ale site-ului — pasul care face inutilizabile eventualele credențiale copiate anterior;
7. am schimbat parola bazei de date.

Fără nicio secundă de întrerupere: site-ul a rămas funcțional pe tot parcursul intervenției, iar conținutul — articole, pagini, documente, imagini — a rămas intact, diacritice incluse.

Securizarea: să nu se mai poată repeta pe aceeași cale

• Parolă suplimentară înainte de formularul de autentificare. Cerută la nivel de server, oprește complet atacurile automate — indiferent câte încercări s-ar face, nu ajung niciodată la WordPress. Este singura schimbare vizibilă pentru administratori.
• Blocarea instalării de module noi din interfața de administrare — mecanismul folosit repetat de atacator.
• Dezactivarea interfeței xmlrpc la nivel de server, folosită pentru amplificarea atacurilor de forță brută.
• Blocarea expunerii publice a numelor de utilizator.
• Interzicerea execuției de cod în directorul de fișiere încărcate, inclusiv pentru extensiile alternative pe care serverul le accepta.
• Activarea alertelor de securitate care erau instalate, dar oprite: autentificări eșuate, atacuri prin forță brută, autentificări reușite, instalări de module.
• Izolarea aplicațiilor vechi rămase pe server din perioada 2009–2017: conținutul lor rămâne accesibil, dar codul nu se mai poate executa.
• Un jurnal de erori de 51 MB, nerotit de ani de zile, a fost golit și pus sub rotație automată.

Verificările de la final

O curățare e completă doar dacă poate fi demonstrată. Verificările noastre, toate trecute:

• 0 fișiere WordPress modificate față de versiunea oficială
• 0 fișiere străine adăugate în instalare
• 0 urme rămase în baza de date
• 0 urme rămase în paginile publicate
• 0 sesiuni active ale atacatorului
• conținutul verificat integral după curățare, inclusiv diacriticele

Ce i-am spus clientului deschis: curățarea nu e suficientă

Intervenția a eliminat infecția și a închis calea prin care s-a produs. Rămâne însă o problemă structurală care nu se rezolvă printr-o curățare — site-ul rulează pe componente ieșite din suport:

• WordPress 4.7 — ramură din 2016;
• PHP 7.4 — suport încheiat în noiembrie 2022;
• un plugin de slider din 2017, cu vulnerabilități publice cunoscute;
• un constructor vizual din 2017;
• un plugin de formulare cu vulnerabilitate publică de încărcare de fișiere;
• un plugin de traducere din 2017;
• o temă comercială pe care producătorul nu o mai întreține.

Fiecare dintre acestea reprezintă o cale de atac posibilă, independentă de cea folosită acum. Măsurile de securizare aplicate reduc semnificativ riscul, dar nu îl elimină.

Recomandarea noastră a fost un proiect separat de modernizare — trecerea la WordPress 6.x și PHP 8.2, cu reconstrucția temei. Actualizarea directă nu este posibilă: tema și modulele actuale nu funcționează pe versiunile moderne, iar site-ul ar deveni inaccesibil. Este o investiție care nu poate fi amânată la nesfârșit; cât timp aceste componente rămân în funcțiune, o nouă compromitere este o chestiune de timp, nu de probabilitate.

Am semnalat separat și o problemă de monitorizare: jurnalele de acces ale serverului se ștergeau zilnic. Din acest motiv nu am putut stabili cu certitudine cum a fost obținută parola inițială și nu am putut reconstitui activitatea atacatorului din prima săptămână. Am cerut mărirea perioadei de păstrare, astfel încât un eventual incident viitor să poată fi investigat complet.

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)

Marker în conținut

<script>;!function(){var _0x2b22=atob('E11OVVhPUlRV…

Ofuscare

base64 urmat de XOR cu cheia 0x3b, bloc de 3021 caractere

Contract Polygon mainnet

0x0C7Cb01C83203aC0a50Abc3a9AFF3c9Ca727eF55

Identificator campanie

bfa8d66687ce0fd20ad81e377f3d0a63841b42231a0c7f95

Module malițioase din istoricul jurnalelor

wp_pushup (activ din aprilie 2023 până în mai 2026 — aproximativ 3 ani nedetectat) · wp-helper-3fc698 · wp-helper-NfcN · wp-file-manager · hseo · xadvanced-traffic-monitor-jveke

Intervale IP dominante

104.207.x · 168.80.x · 65.111.x · 216.26.x · 209.50.x

Semne de reinfectare, de urmărit

apariția textului atob( în conținutul articolelor · autentificări reușite din intervalele IP de mai sus · directoare de module cu nume terminat în sufix aleatoriu