Cercetătorii în securitate au documentat un backdoor WordPress conceput să reziste exact genul de curățare care, de obicei, pune capăt unei infecții. În loc să existe într-un singur fișier, malware-ul — urmărit de investigatori sub denumirea internă "SC" — se plantează simultan în până la opt locații pe un site compromis, iar fiecare copie este conectată să reconstruiască toate celelalte.
Ce s-a întâmplat
Analiștii de la firma de securitate Sucuri au urmărit backdoor-ul în fișiere drop-in WordPress, o temă clonată, un plugin fals instalat în două locații separate, baza de date a site-ului și — pe serverele care o suportă — un bloc de memorie partajată System V. Eliminarea unei singure componente nu ajută: în momentul în care un fișier curățat este cerut din nou, o copie supraviețuitoare îl decodează, îl decompresează și îl restaurează fără zgomot.
Componentele malware-ului nu folosesc nume de funcții lizibile; codul este descifrat la runtime printr-un cifru de substituție, ceea ce a ajutat backdoor-ul să se confunde cu fișierele normale WordPress în timpul răspunsului inițial la incident.
Cel mai neobișnuit strat de persistență se află în memoria RAM, nu pe disc. Pe serverele care suportă memorie partajată System V, backdoor-ul își scrie payload-ul într-un segment de memorie legat de o cheie numerică fixă, nu de un nume de fișier. Acel segment nu dispare când fișierele sunt șterse sau baza de date este golită, iar pe găzduirea partajată poate supraviețui chiar și sub un cont complet diferit față de cel compromis inițial.
Backdoor-ul își înregistrează și propriile sarcini cron WordPress — combinând nume de hook-uri aleatorii cu un hook de "fetch" constant — astfel încât site-ul continuă să raporteze și să se redeploy-eze după un program, indiferent dacă site-ul este vizitat sau nu.
Odată instalat, backdoor-ul oferă atacatorului control complet de la distanță: injectarea de JavaScript arbitrar pentru a livra vizitatorilor skimmere sau alt malware, executarea de cod PHP la cerere și activarea sau ștergerea altor plugin-uri pentru a-și acoperi urmele. Canalul de comandă și control este rutat prin infrastructură blockchain, ceea ce face ca traficul de "raportare" să fie mult mai greu de blocat decât un domeniu sau o adresă IP convențională.
Modul exact în care a avut loc intruziunea inițială nu este încă confirmat, dar cercetătorii indică punctele de intrare obișnuite pentru WordPress: plugin-uri și teme neactualizate, credențiale slabe de administrator, componente compromise din lanțul de aprovizionare software și funcționalități nesigure de încărcare a fișierelor.
Separat, o vulnerabilitate de injecție SQL neautentificată, de severitate ridicată, în pluginul wpForo Forum (afectând toate versiunile până la 2.4.14) este deja exploatată activ, la volum redus, de la câteva adrese IP de atacatori răspândite în mai multe țări — o reamintire că acest tip de mecanism de persistență ajunge de obicei printr-un plugin neactualizat, nu printr-un zero-day în nucleul WordPress.
De ce contează
Majoritatea fluxurilor de curățare WordPress presupun că infecția trăiește în fișiere pe care un administrator le poate vedea și șterge. Un backdoor care trăiește și în baza de date, și în memoria volatilă, anulează complet această presupunere — un site poate părea curat după eliminarea unui plugin și o scanare antimalware, și totuși să fie complet compromis o oră mai târziu. Pentru agențiile și proprietarii de site-uri care tratează "șterge pluginul malițios" drept soluție, acesta este un exemplu direct contrar: remedierea trebuie să acopere toate straturile de stocare deodată, altfel nu este o remediere.
Ce trebuie făcut
- Tratați orice fișier drop-in suspect (
advanced-cache.php,db.php,object-cache.php) dinwp-content/ca semnal de alarmă — acestea nu sunt de obicei prezente pe o instalare WordPress standard și sunt ținte preferate pentru acest tip de persistență. - Când reconstruiți un site compromis, nu vă opriți la fișiere: auditați baza de date pentru hook-uri cron injectate și intrări neașteptate în opțiuni și, pe serverele care o suportă, verificați segmentele de memorie partajată System V orfane.
- Mențineți fiecare plugin și temă la zi și eliminați tot ce este inactiv — vulnerabilitatea de injecție SQL exploatată activ din wpForo este un exemplu concret al modului în care un singur plugin neactualizat deschide ușa.
- Impuneți credențiale de administrator puternice, unice, și autentificare multi-factor, deoarece acreditările slabe de autentificare rămân una dintre cele mai comune căi prin care atacatorii obțin primul punct de sprijin necesar pentru a planta o astfel de persistență.
- În caz de dubiu după o curățare, reconstruiți site-ul dintr-un backup cunoscut ca fiind curat și rotiți toate credențialele și cheile API asociate, în loc să vă bazați pe o eliminare parțială.