Proprietarul unui site web ne-a contactat după ce site-ul său a fost compromis și umplut cu peste 6.000 de articole despre jocuri de noroc. În ciuda ștergerilor repetate pe care le făcea, malware-ul restaura conținutul spam.
Am migrat site-ul către o găzduire premium de la Simplenet, unde la plata anuală includem un audit de securitate și o scanare antivirus.
Auditul a început de la copia de rezervă brută din cPanel pusă la dispoziție de client, care a scos la iveală una dintre cele mai extinse infecții pe care le-am întâlnit anul ăsta.
Vom parcurge infrastructura construită de atacator: ordinea în care a fost desfășurată, modul în care componentele comunică între ele și rolul fiecăreia.
Ce au construit atacatorii
Înainte de a detalia fiecare componentă, iată un rezumat.
Atacatorul a plantat un motor de generare a conținutului, un sistem de rutare care direcționa traficul motoarelor de căutare către conținutul generat, un webshell cu auto-reparare pentru a-și menține accesul la site și un set de mecanisme de siguranță pentru a se asigura că infecția supraviețuiește ștergerii fișierelor individuale.
Scopul celor peste 6.000 de articole despre jocuri de noroc era de a genera trafic din Google și de a-l monetiza prin afiliere cu redirecționări către site-uri de jocuri de noroc.
Mai multe payload-uri distincte au lucrat împreună pentru a face acest lucru posibil, fiecare detaliat mai jos.
Cronologia atacului
Aceasta este secvența operațională pe care am reconstruit-o din mtime-urile fișierelor, structura codului și modul în care componentele se referă unele la altele. Unele date sunt aproximative, deoarece copia de rezervă păstrează doar ultimul mtime, nu întreg istoricul modificărilor.
Intrarea inițială
Cele mai vechi artefacte din copia de rezervă datează din noiembrie 2024 (un stub gol php-console-2). Primele payload-uri „reale” poartă marcaje temporale din februarie 2026.
Analiza fișierelor de pe disc, de una singură, nu a confirmat vectorul inițial de intrare. Familia de atacatori care lasă aceste payload-uri specifice intră de obicei prin plugin-uri vulnerabile și neactualizate (LayerSlider, RevSlider și plugin-urile de tip file-manager sunt cele clasice) sau prin credențiale de administrator furate.
Construirea motorului de spam
Odată intrat, atacatorul a încărcat un plugin fals numti „Yoast Helper” (folderul numit smush-508) care a publicat în masă articolele spam din fișiere TXT și CSV incluse, a plantat injecția malware în șase fișiere functions.php ale unor teme WordPress pentru a masca spam-ul și a redirecționa vizitatorii și a păstrat o copie curată a fiecărui functions.php original ca mecanism de siguranță pentru revenire, în cazul în care propria injecție ar fi stricat site-ul.
Construirea C2 și a punctelor de intrare redundante
Apoi a construit sistemul de control de la distanță. Două tabele în baza de date (wp_pcachewpr și wp_lcachewpr) păstrau endpoint-urile de comandă și control și hărțile de rutare a URL-urilor care legau fiecare articol fals de conținutul său mascat.
28 de fișiere cu nume hexazecimale au fost împrăștiate prin wp-content/ ca soluții de rezervă pentru execuția de cod, în cazul în care celelalte backdoor-uri ar fi fost curățate. Iar plugin-ul numit woocommerce_TAG prindea vizitatorii sosiți de la motoarele de căutare și îi redirecționa către linkuri spam de afiliere.
Persistență și ascunderea contului de administrator
La următorul pas, atacatorul și-a asigurat accesul pe termen lung.
Două backdoor-uri puse ca pluginuri de tip mu-plugin se încărcau automat la fiecare cerere și nu puteau fi dezactivate din interfața de administrare. Plugin-ul wp-system-cache se ascundea atât pe sine, cât și un cont secret de administrator, iar două instrumente legitime de dezvoltare (wp-console și mai multe variante php-console) au fost reutilizate ca webshell-uri în browser.
Atacatorul a rescris și robots.txt în întreaga rețea pentru a bloca crawlerele SEO și de securitate, direcționând în același timp Google direct către sitemap-uri malițioase pentru paginile de cazinouri și păcănele.
Blocarea finală
Ultima și cea mai sofisticată componentă a fost injectată în jurul datei de 29 aprilie 2026: un webshell cu auto-reparare conectat în wp-config.php.
Un handler de reparare reconstruiește un file manager ascuns ori de câte ori site-ul întâmpină o eroare fatală, apoi blochează fișierele astfel încât să nu poată fi șterse cu ușurință. Mecanismele complete sunt explicate detaliat la secțiunea „Un handler de cache cu auto-reparare” de mai jos.
Marcarea teritoriului
În final, atacatorul a lăsat markere goale de coordonare a boților (config-main.php, 1.php și altele similare) în rădăcina unui subdomeniu. Alte scripturi automate din aceeași familie verifică prezența acestor markere înainte de a rula, ca să nu irosească resurse reinfectând un site caree deja infectat.
Componentele malware-ului
Cronologia de mai sus este succesiunea evenimentelor. Această secțiune este referința: fiecare componentă în detaliu, organizată după funcție.
Un handler de cache cu auto-reparare
Aceasta este injecția din wp-config.php, delimitată de comentariul /* WP_CACHE_INTEGRITY_MARKER */.
Ea definește wp_cache_repair_handler(), care decodează un blob lung în base64 și îl scrie în trei locații ascunse:
wp-includes/.wp-cache-handler.php
wp-content/.wp-temp-data.php
wp-content/uploads/.cache/.wp-session-backup.phpPayload-ul decodat este o clasă numită FM_Standalone: dacă deții token-ul corect, obții un file manager în browser (listare, încărcare, descărcare, editare, redenumire, chmod, mkdir, touch, ștergere și shell_exec) stilizat să arate ca un instrument de dezvoltare.
O regulă RewriteRule din .htaccess direcționează orice URL care poartă ?wp_cache_token=<token> direct către handler:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{QUERY_STRING} (wp_cache_token|wp_token)= [NC]
RewriteRule .* wp-includes/.wp-cache-handler.php [L]
</IfModule>Injecția apelează și register_shutdown_function(), astfel încât orice eroare PHP fatală re-declanșează wp_cache_repair_handler() și recreează cele trei fișiere dacă lipsesc.
Fiecare fișier primește chmod 0444, iar directorul său părinte 0555, așa că nici măcar cu file manager-ul nu poți șterge fișierele fără să escaladezi mai întâi permisiunile. Hook-ul de shutdown plus blocarea permisiunilor sunt cele care fac acest strat capabil de auto-reparare.
Pentru a-l elimina curat:
- extrageți blocul din
wp-config.phpde la comentariul marker până la finalul apeluluiregister_shutdown_function(...), - eliminați blocul de rewrite din
.htaccess, - apoi rulați
chmod u+wpe directoarele părinte înainte de a șterge cele trei fișiere.
Odată dispărută funcția de reparare, fișierele rămân șterse.
Fișiere hexazecimale de 8 caractere
Malware-ul a plasat 28 de fișiere (droppers) care corespund tiparului [a-f0-9]{8}.php, împrăștiate prin wp-content/ pe fiecare site. Exemple de căi:
/wp-content/57cc122f.php
/wp-content/uploads/fef52e38.php
/wp-content/uploads/2a591b72.php
/wp-content/plugins/LayerSlider/4dad4931.php
/wp-content/uploads/e421bb14.php
/wp-content/plugins/astra-sites/7e67294f.phpFiecare folosește ofuscare prin divizarea șirurilor pentru a ține numele de funcții periculoase în afara textului simplu:
Acestea sunt executoare de cod fără stare. Trimite un payload PHP codat în base64 ca $_POST['319d3823'] (sau echivalentul GET), iar dropper-ul îl decodează, scrie <?php plus payload-ul într-un tempnam din directorul temporar al sistemului, îl include cu include_once() și îl șterge imediat cu unlink().
Dropper-ul în sine nu conține niciun apel eval sau system, așa că scanerele anti-malware bazate pe semnături îl ratează adesea. Execuție completă de cod, fără urmă persistentă a ceea ce a fost rulat de fapt.
O singură comandă find . -type f -name "[a-f0-9][a-f0-9][a-f0-9][a-f0-9][a-f0-9][a-f0-9][a-f0-9][a-f0-9].php" le găsește pe toate pe un site compromis din această familie.
Verificați potrivirile înainte de ștergerea în masă pe conturile unde nu sunteți la fel de siguri.
O injecție în functions.php din teme
Șase fișiere functions.php de teme aveau un payload încadrat între două comentarii marker MD5 identice:
/themes/betheme/functions.php /* 7fb5cc8fcbfb7ec15164f8453d98c308 */
/themes/twentytwentyfour/functions.php /* 8ef89a2c935520f8385a4c56233137cb */
/themes/twentyseventeen/functions.php /* 1f914a54ec0902be962df8fff5928648 */
/themes/kids-campus/functions.php /* 15eb60cb816e27da92bfac0fc695e90b */În interiorul markerelor, codul extrage două payload-uri din wp_options:
Blob-urile deserializate sunt indexate după ID-ul autorului articolului. Când un vizitator nelogat accesează un URL de articol individual, malware-ul potrivește URL-ul cu regulile de rewrite per-autor, apoi fie injectează JavaScript malițios prin wp_head / wp_footer, fie declanșează un template_redirect.
Filtre precum posts_where_paged, pre_get_posts și rewrite_rules_array sunt folosite pentru a ascunde conținutul spam de administratorii logați.
Curățarea este un proces în doi pași. Codul PHP dintre markere trebuie eliminat chirurgical (un mic script care găsește markerul de deschidere și perechea sa de închidere funcționează pe toate cele șase fișiere).
Cele două rânduri din wp_options care îl alimentau (wp_custom_filters și MD5-ul per-gazdă) sunt inerte fără PHP, dar ar trebui totuși șterse din baza de date a fiecărui site.
Familia de funcții eefw_* (eefw_home_hosts, eefw_allowed_hosts, eefw_url_allowed) este semnătura aceluiași atacator, găsită atât în interiorul plugin-ului smush-508, cât și ca un „shim de securitate” lipit în functions.php din tema Betheme, între markerele // eefw-security-508-start și // eefw-security-508-end: același operator, același set de instrumente.
Tabelele de C2 și de rutare din baza de date
Aici se află sistemul de rutare a URL-urilor de spam.
Două tabele personalizate, wp_pcachewpr și wp_lcachewpr, conțin BLOB-uri codate hexazecimal. Decodate, ele conțin:
- Endpoint-urile C2 pe care malware-ul le interoghează pentru instrucțiuni.
- Tablourile de configurare care descriu câte linkuri de spam să injecteze pe pagină.
- Hărțile exacte de rutare a URL-urilor care leagă fiecare slug de articol fals de conținutul său mascat.
Stocarea datelor de rutare în tabele personalizate de bază de date (în loc de wp_options) evită scanerele generice de bază de date care verifică doar wp_options, wp_postmeta și wp_posts. Codarea hexazecimală a BLOB-urilor adaugă încă un strat de evaziune.
Aceste tabele trebuie eliminate cu DROP în timpul curățării. Comanda SQL se află la secțiunea „Cum am curățat și restaurat site-ul” mai jos.
robots.txt și sitemap-uri malițioase
În întreaga rețea, robots.txt a fost rescris cu modificările îngropate sub sute de rânduri goale.
Atacatorul a adăugat reguli Disallow: / îndreptate către crawlerele SEO și de securitate (AhrefsBot, MJ12bot, SemrushBot, DotBot), pentru ca scanerele externe să nu scoată la suprafață linkurile de spam, apoi a adăugat directive Sitemap: personalizate care indicau spre hărți XML malițioase precum /.wp-toolkit_E/live-casino/sitemap.xml și /gambling-board/sitemap.xml.
Acele sitemap-uri îi spuneau Google exact unde să găsească cele peste 6.000 de pagini de cazinouri și păcănele.
Plugin-uri de ascundere
Am mai descoperit trei plugin-uri, fiecare conceput să rămână invizibil pentru proprietarul site-ului.
woocommerce_TAG
Nu are nicio legătură cu WooCommerce. Prefixul „WooCommerce” este o inginerie socială: proprietarii de site-uri evită să atingă orice are WooCommerce în nume, de teamă să nu-și strice magazinul.
Ce face pluginul ăsta?
- se conectează la
template_redirect, - verifică dacă există un referrer de la un motor de căutare și redirecționează vizitatorii care sunt la prima vizită.
- se ascunde din pagina de plugin-uri.
- elimină linkul de dezactivare.
- folosește un cookie de 24 de ore pentru a împiedica vizitatorii să fie redirecționați de două ori și pentru a evita suspiciunile.
wp-system-cache
Se identifică drept „WP Cache Performance” de la „WordPress”, dar nu are nicio legătură nici cu echipa WordPress, nici cu performanța, nici cu cache-ul.
Folosește un sistem de auto-ascundere standard prin unset($plugins[plugin_basename(__FILE__)]).
Partea interesantă este ce mai ascunde: filtrează pre_user_query, views_users și endpoint-ul REST de utilizatori pentru a elimina un anumit cont de administrator (controlat de opțiunea _wpc_cx, implicit wp_ + hash CRC32) din fiecare listă și ocolește Force Login pe API-ul REST.
Plugin-ul se ascunde atât pe sine, cât și contul de administrator al atacatorului.
smush-508
Se identifică drept „Yoast Helper” de la „Team Yoast”, deși nu are nicio legătură cu adevăratul plugin Yoast SEO; numele este doar de camuflaj.
Aceeași tehnică de auto-ascundere. Găzduiește și motorul de generare a articolelor spam: o acțiune admin_init citește fișiere TXT dintr-un subdirector posts/ și un CSV de la wp-content/uploads/2024/11/508.csv, apoi apelează wp_insert_post pentru a le publica în masă.
Aceasta este sursa celor peste 6.000 de articole pe care le-a văzut clientul.
Backdoor-urile de tip mu-plugin
Două dintre ele:
mu-plugins/direct-connector-mod.php
"Smart Toolkit Live" by "Digital Works Studio"
mu-plugins/core-plugin-bit.php
"Primary Dispatcher Kit" by "Rachel Mitchell"direct-connector-mod.php era prezent în 10 locații. core-plugin-bit.php în 3.
Ambele fișiere folosesc același tipar de ofuscare: sute de variabile, fiecare conținând un scurt fragment base64, completate cu caractere de umplutură ca zgomot de fond, apoi reasamblate în timpul rulării în nume de funcții.
Odată decodate, scripturile contactează gazde C2 la distanță, interoghează pentru instrucțiuni, scriu fișiere noi și modifică baza de date.
Antetele plugin-urilor sunt camuflaj. Nu există niciun plugin numit „Smart Toolkit Live” pe wordpress.org. Nu există niciun dezvoltator „Digital Works Studio” cu acel autor.
Antetul este acolo pentru ca atunci când cineva aruncă o privire pe fișier să creadă că este un plugin legitim.
Plugin-uri legitime folosite ca instrumente de atac
Două plugin-uri reale au fost reutilizate ca backdoor-uri.
wp-console
Acesta este un plugin legitim creat de Edi Amin, care livrează un PsySH PHP REPL în browser, în interiorul panoului de administrare WordPress.
Este folosit din comoditate, dar este, efectiv, un webshell. Instalarea WP Console este o mișcare secundară frecventă după ce un atacator obține credențiale de administrator, deoarece backdoor-ul rezultat nu lasă o urmă evidentă de fișier malițios.
L-am găsit în două subdomenii, plus trei directoare-stub goale (php-console-actual, php-console-2 și php-console-mu-4.3) în alte părți.
wp-file-manager
Acest plugin exista în 13 locuri. Este un plugin legitim care a avut mai multe CVE-uri de tip RCE neautentificat de-a lungul anilor. Chiar și actualizat, expune un file manager liber oricui are drepturi de administrator.
L-am întrebat pe client dacă el a instalat aceste plugin-uri, iar când a spus că nu, le-am eliminat peste tot.
Notă: nu recomandăm folosirea acestor pluginuri. Este absolut ireal cum astfel de pluginuri sunt acceptate în repo-ul WordPress.org, sunt folosite pe scară largă și au review-uri de 5 stele, iar ele sunt găuri masive de securitate pe orice site pe care sunt instalate.
Rămășițe
Odată eliminate payload-urile active, o ultimă verificare a scos la iveală mai multe rămășițe ale infecției:
- wp-promtools-pro/functions_bak.php în patru subdomenii. Copii curate ale fișierelor functions.php originale, păstrate ca mecanisme de siguranță, pentru ca injectorul de malware să poată reveni dacă propriile modificări stricau site-ul.
- Shell-uri goale de plugin-uri cu nume luate de la produse WordPress reale (wp-core-*-module, wp-engine-*-module, wp-kernel-module, zend-fonts-wp, opt_v13od7) aflate în .wp-toolkit_E/ și în folderul .trash/ al cPanel.
- custom-socializer-tracking-post, un „plugin de monitorizare” din /wp-content/plugins/ care exfiltrează date despre site către o instanță MongoDB controlată de atacator. Comentarii în limba rusă în codul sursă.
- Foldere de plugin-uri false cu nume care par legitime la prima vedere: contact-form-7-pro (nu există oficial un astfel de plugin), all-in-one-seo-pack-stable și wordpress-seo-extended (o clonă falsă cunoscută de Yoast SEO folosită de această familie de atacatori).
- Markere de coordonare a boților în folderul rădăcină al unui subdomeniu: config-main.php, config-main_2506.php și 1.php. Folosite de scripturile automate ale atacatorului pentru a recunoaște „deja deținem acest site”.
- Un fișier index-encryption.php de 0 octeți într-un director de plugin.
- Aproximativ 250 de directoare goale rămase de la upgrade-uri vechi de plugin-uri, staging .wp-toolkit_* și foldere de upload.
Cum am curățat și restaurat site-ul
În interiorul arhivei de rezervă, am lucrat mai întâi la fișiere:
Fișiere de bază igienizate
Am eliminat blocul de injecție base64 cu auto-reparare din wp-config.php și blocul malițios mod_rewrite din .htaccess.
Fișierele webshell distruse
Am forțat ștergerea .wp-cache-handler.php, .wp-temp-data.php și .wp-session-backup.php după relaxarea permisiunilor directoarelor părinte.
Micro-dropperele eliminate
O verificare globală a identificat și a șters definitiv toate cele 28 de fișiere PHP hexazecimale de 8 caractere.
Injecțiile din functions.php curățate
Un mic script a eliminat chirurgical blocurile de malware încadrate cu MD5 din toate cele șase teme afectate, precum și shim-ul eefw-security-508. Codul legitim al temelor a fost lăsat intact.
Plugin-uri malițioase eliminate
Am șters wp-system-cache, woocommerce_TAG, smush-508, wp-promtools-pro, toate variantele wp-console și php-console, direct-connector-mod.php, core-plugin-bit.php, custom-socializer-tracking-post, index-encryption.php, wordpress-seo-extended, contact-form-7-pro și all-in-one-seo-pack-stable.
Instrumente legitime exploatate eliminate
Am șters wp-file-manager din toate cele 13 locații pentru a elimina un vector cunoscut de reinfectare.
robots.txt restaurat
Am eliminat directivele malițioase Disallow: și Sitemap: din cele 9 fișiere modificate. Le-am înlocuit cu valorile implicite standard și sigure pentru WordPress.
Marcaje de boți și gunoaie curățate
Am eliminat fișierele marker goale (config-main.php, 1.php etc.) și am golit folderul .trash/ al cPanel, care conținea încă variante mai vechi, dormante, ale malware-ului.
Proprietarul site-ului a șters manual cele peste 6.000 de articole spam din baza de date înainte de analiza noastră finală.
Cu fișierele curate, baza de date și credențialele mai aveau nevoie de lucru înainte ca site-ul să poată reveni în siguranță online. Ne-am ocupat de o parte noi înșine și am ghidat clientul prin restul, în această ordine:
- curățarea bazei de date
- verificarea conturilor de utilizator
- schimbarea parolelor
- actualizări de software
Fiecare este detaliat mai jos. Ordinea contează: baza de date trebuie curățată și plugin-ul de ascundere a utilizatorilor eliminat înainte ca acel cont de administrator necinstit să devină vizibil, iar credențialele se rotesc înainte ca site-ul să fie expus din nou. La Simplenet rămânem implicați și după acest punct, ajutând clienții să fie atenți la reinfectare pe măsură ce site-ul revine online.
Curățarea bazei de date (SQL)
Rulăm următoarele prin phpMyAdmin pentru a elimina tabelele de rutare C2 și pentru a curăța metadatele orfane rămase de la articolele spam șterse.
-- 1. Drop the malware routing tables
DROP TABLE IF EXISTS `wp_pcachewpr`, `wp_lcachewpr`;
-- 2. Clean up orphaned post metadata (remnants of the 6k deleted spam posts)
DELETE FROM wp_postmeta WHERE post_id NOT IN (SELECT ID FROM wp_posts);
-- 3. Clean up orphaned user metadata
DELETE FROM wp_usermeta WHERE user_id NOT IN (SELECT ID FROM wp_users);
-- 4. Clean up orphaned term relationships
DELETE FROM wp_term_relationships WHERE object_id NOT IN (SELECT ID FROM wp_posts);De asemenea, ștergeți, pe fiecare site, orice rând din wp_options numit wp_custom_filters, plus orice rând al cărui nume corespunde cu md5(sha1(<hostname-ul acelui site>)).
Acestea erau spațiul de stocare al injecției Balu. Sunt inerte fără codul PHP din temă care le citea, dar ar trebui totuși eliminate.
Curățarea contului de administrator ascuns
Plugin-ul wp-system-cache exista special pentru a ascunde un administrator creat de atacator din lista de utilizatori WordPress. Plugin-ul a dispărut, dar utilizatorul ar putea fi încă în baza de date.
Pentru a evita ștergerea utilizatorilor legitimi, i-am cerut proprietarului site-ului să revizuiască toți utilizatorii și să șteargă orice cont de administrator pe care nu îl recunoaște, acordând o atenție specială numelor de utilizator care încep cu wp_ urmat de caractere cu aspect aleatoriu.
Rotația credențialelor
Atacatorii au avut acces de citire la wp-config.php prin file manager cel puțin în perioada de la 29 aprilie încoace și, probabil, mult mai mult timp prin backdoor-urile mu-plugin. Trebuie să presupunem că datele de acces la baza de date sunt publice, așa că i-am cerut clientului să schimbe:
- Parola panoului de control.
- Toate parolele FTP / SSH.
- Toate parolele utilizatorilor bazei de date (și să actualizeze ulterior constanta corespunzătoare
DB_PASSWORDdin fiecare wp-config.php). - Toate parolele administratorilor WordPress. Forțați resetarea acestora în loc să trimiteți linkuri de recuperare prin e-mail.
Actualizări de software
I-am cerut clientului să actualizeze nucleul WordPress, fiecare temă și fiecare plugin la versiunile curente înainte de a expune din nou site-urile pe internet. Vectorul inițial de intrare nu a fost confirmat în timpul curățării, dar familia de atacatori care lasă aceste payload-uri specifice obține de obicei acces prin plugin-uri neactualizate sau prin credențiale de administrator furate.
De asemenea, i-am recomandat clientului nostru să trimită sitemap-ul curat sitemap.xml către Google Search Console și să solicite reindexarea pentru a accelera eliminarea celor peste 6.000 de URL-uri spam din rezultatele căutării. Apoi să urmărească raportul de acoperire din Search Console timp de câteva săptămâni.
Dacă reapar URL-uri spam noi, acesta este un semnal că procesul de curățare a ratat ceva și că site-ul ar trebui re-auditat.
Confirmarea faptului că site-ul era curat
După toate cele de mai sus, o nouă verificare a confirmat următoarele în întregul cont:
- Fișierele wp-config.php nu conțin niciun apel
evalsaubase64_decode. - Fișierele .htaccess nu conțin nicio regulă
wp_cache_tokensauwp_token. - Nu mai rămâne niciun fișier .php hexazecimal de 8 caractere nicăieri.
- wp-load.php, wp-settings.php, wp-blog-header.php și fișierele index.php din nucleul WordPress sunt nemodificate.
- Nu este prezentă nicio semnătură FilesMan, WSO, b374k, c99shell sau r57shell.
- Directoarele mu-plugins nu conțin niciun artefact rămas de la atacator.
- Fișierele functions.php din teme nu conțin niciun bloc de injecție cu marker MD5 și niciun wrapper fals
eefw_. - Directorul .trash a fost golit de rămășițele malware-ului.
- Directoarele .cpanel, mail, .subaccounts, ssl și .cagefs nu au avut niciodată fișiere PHP în ele. Daunele au fost limitate la WordPress.
Ce ne învață acest caz
Acest caz are două lecții.
Prima: amploarea acestei coordonări indică un sistem automatizat de reinfectare.
Îți poți da seama pentru că același tipar de marker MD5 apare în mai multe teme, aceleași droppere cu nume hexazecimale au fost plasate în directoare identice pe fiecare subdomeniu, iar fiecare backdoor are un mecanism de siguranță corespunzător: depozitul de revenire wp-promtools-pro, handler-ul de reparare prin funcția de shutdown, marcajele de coordonare a boților.
A doua: ștergerea articolelor spam nu elimină infecția.
Proprietarul a făcut ce trebuia, ștergând 6.000 de articole din baza de date. Totuși, motorul care le-a generat era încă în smush-508, tabelele de rutare erau încă în baza de date, iar file manager-ul era încă pregătit să repare orice reușea el să șteargă.
Ștergerea articolelor a eliminat simptomele vizibile; mecanismul care le producea a continuat să funcționeze.
Cum să vă protejați propriul site
Punctele de intrare folosite de acest atacator sunt aceleași pe care le puteți închide în avans. Tratați acest lucru ca pe o mentenanță de rutină, nu ca pe un lucru pe care-l faceți o singură dată și gata:
- mențineți toate plugin-urile, temele și nucleul WordPress actualizate.
- folosiți parole puternice și unice pentru fiecare cont.
- activați autentificarea în doi factori pe conturile de administrator.
- eliminați plugin-urile și temele nefolosite sau învechite.
- revizuiți periodic conturile de utilizator și permisiunile.
Puneți-le pe un program recurent. Pentru informații mai complete, vedeți ghidul nostru despre bunele practici de securitate WordPress.
Concluzie
Acesta a fost un sistem coordonat, construit să supraviețuiască ștergerii, să se ascundă de proprietar și să producă bani.
Curățarea lui a însemnat eliminarea fiecărui payload, blocarea permisiunilor, eliminarea tabelelor de rutare și igienizarea fișierelor de bază. Ordinea a contat, deoarece handler-ul de reparare anulează orice ștergi în afara secvenței.
Problemele simple sunt la îndemâna majorității proprietarilor de site-uri: o vulnerabilitate cunoscută de plugin, o temă neactualizată, câteva articole spam evidente.
Infecțiile ca aceasta nu sunt simple.
Payload-uri ascunse, conturi de administrator invizibile, spam care revine în permanență și backdoor-uri care se reconstruiesc singure după ștergere; toate au nevoie de cineva care poate da socoteală pentru fiecare piesă, pentru că lăsarea uneia în urmă readuce întregul sistem.
Dacă malware-ul revine mereu după ce l-ați curățat, acesta este semnalul să aduceți ajutor.
Când vă mutați site-ul la Simplenet, pachetele noastre premium cu plată anuală includ un audit de securitate profesional, o scanare antivirus aprofundată și o migrare curată gestionată de echipa noastră de experți, totul gratuit și fără downtime.
Consultați planurile noastre de găzduire pentru a găsi varianta potrivită pentru site-ul dumneavoastră sau contactați-ne pentru a discuta cum vă putem securiza site-ul dvs. WordPress.
