Anatomie atac: backdoor WordPress deghizat ca plugin

În cei 11 ani de când Web365 administrează servere și site-uri WordPress, am văzut mii de tentative de atac — majoritatea banale, blocate automat de firewall-uri și reguli ModSecurity.

Dar uneori, atacul nu vine cu zgomot. Vine pe vârfuri, deghizat, și se așază liniștit pe site-ul tău săptămâni întregi, fără să-ți dai seama. Iar când îl descoperi, realizezi că ai în spate o operațiune profesionistă, nu un script kiddie.

Articolul de față este povestea reală a unui astfel de incident — un backdoor WordPress C2 (Command and Control) ascuns într-un plugin WordPress aparent inofensiv, descoperit pe un server cPanel administrat de echipa Web365. Am anonimizat detaliile care ar putea identifica clientul, dar pașii tehnici și concluziile sunt exact cele reale.

Citește până la capăt. La final ai un checklist concret de verificat chiar acum pe site-ul tău WordPress.

Cum a început totul: o alertă banală

Era o zi normală de luni. Sistemul nostru de monitorizare a generat o alertă aparent banală: trafic de ieșire crescut pe unul dintre conturile cPanel pe care le administrăm. Nu era nimic alarmant — putea fi un backup mai mare, o sincronizare cu un serviciu extern, o actualizare de plugin care descarcă date.

Dar ceva nu se potrivea. Site-ul în cauză era un proiect de e-commerce de dimensiune medie, cu trafic predictibil. Iar requesturile de ieșire nu mergeau către CDN-uri cunoscute sau servicii standard. Mergeau către trei IP-uri din Asia de Sud-Est, la intervale regulate de 30 de minute.

Atât a fost suficient. Am trecut imediat în mod investigație.

Primele semne suspecte

Verificarea inițială ne-a arătat câteva indicatori care, separat, n-ar fi însemnat nimic. Împreună, formau un pattern îngrijorător:

Cron jobs noi care nu fuseseră create de admin
Fișiere PHP modificate recent în directorul /wp-content/plugins/ fără ca clientul să fi instalat plugin-uri noi
Conexiuni active către IP-uri externe, persistente, vizibile cu netstat
Procese PHP-FPM cu consum de memorie ușor crescut, dar nu suficient cât să declanșeze alerte de quota

Și ceva mai subtil: un plugin numit cdn-performance-monitor activ în site. Un nume care suna legitim — exact genul de unealtă pe care un administrator tehnic ar instala-o pentru a monitoriza CDN-ul.

Dar nu îl recunoșteam din repository-ul oficial WordPress. Și clientul nu-și amintea să-l fi instalat.

De ce nu părea o problemă majoră (la început)

Aici este partea înfricoșătoare: niciun scaner antivirus standard nu a detectat plugin-ul. Imunify360, Wordfence, MalCare — toate trecuseră peste el fără să-l flagheze. Motivul? Codul era scris să pară legitim. Nimic nu era eval-uit direct, nu existau funcții obfuscate evidente, nu apăreau șiruri base64 lungi sau gzinflate() agresiv. La o privire superficială, era un plugin de monitorizare normal.

Asta a fost prima lecție: atacatorii moderni nu mai folosesc malware „zgomotos”. Au învățat să se adapteze la scaner-e și să se camufleze.

Investigația: săpând mai adânc

Cu un suspect identificat, am trecut la analiza manuală a codului. Am copiat plugin-ul într-un mediu izolat (sandbox) și am început să-l citim, linie cu linie.

Structura plugin-ului

Plugin-ul avea structură WordPress standard:

Fișier principal cdn-performance-monitor.php cu header valid (Plugin Name, Version, Author)
Director /includes/ cu fișiere de „module”
Director /assets/ cu CSS și JS aparent legitime
Fișier readme.txt cu descriere convingătoare despre monitorizare CDN

Restul plugin-ului avea funcționalitate reală — chiar afișa un dashboard în wp-admin cu metrici de cache. Era exact ce făcea un plugin de monitorizare CDN normal.

Dar într-unul dintre fișierele modulelor, am găsit ceea ce căutam.

Codul care a stârnit suspiciuni

Într-un fișier numit aparent banal — includes/class-cache-stats-collector.php — exista o clasă cu o metodă numită collect_stats(). La prima vedere, colecta metrici de cache. La a doua vedere, făcea altceva.

Metoda apela o funcție internă care:

Construia un payload cu informații despre server (versiune PHP, lista plugin-urilor active, conturi WordPress admin, structura DB)
Cripta payload-ul cu AES-256-GCM folosind o cheie hardcoded în plugin
Trimitea payload-ul printr-un POST către unul dintre cele trei IP-uri C2 identificate inițial
Aștepta răspuns — care, decriptat, conținea comenzi de executat pe server

Era un agent C2 complet funcțional, scris profesionist, ascuns într-un plugin WordPress.

Anatomia unui backdoor WordPress

Hai să descompunem ce făcea backdoor-ul, pentru că merită înțeles tehnic. Cunoașterea inamicului este primul pas pentru a-l combate.

Comunicare criptată AES-256-GCM

AES-256-GCM este un algoritm de criptare militar-grade, folosit de Signal, WhatsApp, TLS modern. Nu este ceva ce găsești într-un script de malware obișnuit — este alegerea unui dezvoltator care știe ce face.

Beneficiile pentru atacator:

Trafic indistinct de comunicare HTTPS legitimă — proxy-urile și WAF-urile nu pot inspecta conținutul
Autentificare integrată (GCM) — atacatorul știe că răspunsul vine de la victima reală, nu de la un cercetător care încearcă să-l capteze
Imposibil de spart fără cheie — chiar dacă cineva capta tot traficul, nu putea recupera conținutul

Comenzi remote executate la cerere

După decriptarea răspunsurilor C2, am identificat tipurile de comenzi pe care backdoor-ul le putea executa:

Exfiltrare date: orice fișier de pe server (inclusiv wp-config.php cu credențiale DB)
Execuție arbitrară PHP: rulare cod la alegerea atacatorului
Modificare DB: creare conturi admin, schimbare parole, injecție în articole
Upload fișiere: instalare alte plugin-uri malițioase sau pagini de phishing
Pivot lateral: încercare de acces la alte conturi de pe același server

Tot acest arsenal pornea de la o singură cerere POST periodică, programată prin cron job WordPress (wp_schedule_event) — nu prin cron-ul de sistem, pentru a evita detectarea de către administratorii care verifică doar crontab-ul Linux.

Persistență prin obfuscare inteligentă

Ce făcea acest plugin diferit de malware-ul clasic:

Niciun eval() direct: codul era executat prin call_user_func() cu nume de funcții construite la runtime
Niciun șir base64 evident: payload-urile erau criptate AES, deci aveau distribuție aleatoare de octeți (indistincte de „noise”)
Niciun include de fișier remote: tot codul rulează local, nimic descărcat de pe alt server
Header de plugin valid: respecta strict standardele WordPress
Dashboard funcțional: oferea valoare aparent reală pentru a evita ștergerea de către admin

Practic, dacă un admin intra în wp-admin → Plugin-uri, vedea un plugin care părea util, instalat, activ, fără warnings. Avea toate motivele să-l lase acolo.

Cum a ajuns plugin-ul pe server

După analiza tehnică, întrebarea naturală: cum a ajuns acolo? Nu există magie — atacatorul a folosit un vector concret.

Vectorul probabil: plugin nullat

Investigația noastră a indicat cea mai probabilă cauză: un plugin premium „nullat” (versiunea piratată a unui plugin plătit, descărcată de pe site-uri shady) instalat cu câteva luni înainte de incident.

Pluginurile nullate sunt vectorul #1 de infectare pentru site-urile WordPress din România și din Europa de Est, conform datelor noastre interne și rapoartelor Patchstack. Sunt distribuite de site-uri care promit „plugin Pro gratis” — iar utilizatorii le instalează pentru a evita licențe de 50-100 EUR.

Ce nu știu utilizatorii: aceste plugin-uri vin frecvent cu plugin-uri secundare instalate în background (cum a fost cdn-performance-monitor), sau cu cod malițios injectat direct.

De ce mecanismele clasice nu l-au prins

Întrebarea legitimă: avea client AIOS instalat, avea firewall server, avea Imunify360. Cum a trecut prin toate?

Răspunsul scurt: pentru că niciun sistem automat nu poate detecta un backdoor scris profesionist care folosește tehnici de evaziune moderne. Scanerele caută:

Funcții PHP suspecte (eval, base64_decode, gzinflate)
Pattern-uri cunoscute de malware (semnături)
Fișiere modificate recent în locații sensibile
Comportament anormal la runtime (cu sandbox)

Plugin-ul nostru evita TOATE aceste categorii. Era prea bine făcut.

Singurul lucru care l-a dat de gol a fost analiza traficului de rețea combinată cu revizia manuală a codului — exact ce un scaner automat NU poate face.

Curățarea: pași pentru a elimina amenințarea

Odată confirmat ce era plugin-ul, am procedat sistematic. Pașii pe care i-am urmat — și pe care orice administrator ar trebui să-i știe pentru un incident similar.

Pasul 1: Izolare imediată

Înainte de orice altceva, am izolat contul cPanel de restul serverului. Asta înseamnă:

Suspendare temporară a accesului public la site
Blocare comunicare outbound către IP-urile C2 identificate (firewall regulile)
Snapshot complet al stării contului (forensic backup)

Greșeala comună aici: să șterg plugin-ul direct, fără backup. Pierzi forensic evidence și nu poți investiga vectorul de intrare ulterior.

Pasul 2: Forensic backup

Am salvat:

Snapshot complet fișiere (cu permissions și timestamps păstrate via rsync -a --backup)
Dump complet bază de date MySQL
Logs Apache/Nginx ultimele 90 zile
Logs cPanel access și security
Backup plugin malițios separat, pentru analiza ulterioară

Toate aceste date au fost trimise echipei de securitate pentru analiza extinsă (incluzând timeline-ul exact al infectării, alte URL-uri compromise, IP-uri sursă ale atacatorului).

Pasul 3: Eliminare completă a infecției

Procesul de curățare nu se limitează la ștergerea plugin-ului. Acesta era doar partea vizibilă. Trebuia să verificăm:

Toate fișierele WordPress core pentru modificări (comparate cu hashurile oficiale wordpress.org)
Toate plugin-urile pentru injecții similare (chiar și cele legitime)
Tema activă pentru cod malițios (este o ascunzătoare comună)
Baza de date pentru conturi admin neautorizate, posturi cu redirect-uri JavaScript, options modificate
wp-config.php pentru chei și salts compromise
.htaccess pentru reguli de redirect malițios
uploads/ pentru fișiere PHP plantate (uploads NU ar trebui să conțină niciodată .php)
Cron jobs la nivel WordPress (wp_options → cron) și la nivel server (crontab -l)

Am găsit alte 3 fișiere modificate și am eliminat tot.

Pasul 4: Hardening post-incident

După cleanup, am asumat că tot ce era pe acel cont era compromis. Asta a însemnat:

Schimbarea tuturor parolelor: cPanel, WordPress admin, FTP, baza de date, API keys
Regenerare salts WordPress (chei criptografice din wp-config.php)
Revocare tuturor sesiunilor active WordPress (toți userii deconectați forțat)
Audit conturi admin: ștergere conturi necunoscute, verificare cele rămase
Verificare integritate baza de date: scanare comentarii, posturi, options
Reinstalare WordPress core din sursa oficială
Reinstalare temei și plugin-urilor din surse oficiale verificate (NICIODATĂ nullate)
Activare 2FA pentru toți userii admin
Configurare WAF mai strict la nivel server

Timpul total al intervenției: aproximativ 18 ore distribuite pe 3 zile, incluzând investigația, cleanup-ul și hardening-ul.

Ce am învățat noi (și ar trebui să înveți și tu)

Acest incident a confirmat câteva adevăruri pe care le predicăm de ani de zile, dar care prind un sens nou când le vezi materializate în fața ochilor.

1. „Plugin gratuit” poate costa foarte scump

Plugin-urile nullate sau de pe surse neoficiale sunt vectorul #1 de infectare. Diferența între un plugin Pro de 50 EUR/an cumpărat oficial și unul „gratis” descărcat de pe forum poate fi între un site funcțional și un site compromis luni de zile. Economisirea aparentă te costă enorm.

2. Scanere antivirus NU sunt suficiente

Imunify360, Wordfence, MalCare — toate sunt utile, dar niciunul nu garantează detecție 100%. Un atacator profesionist scrie cod care evită semnăturile cunoscute. Securitatea reală vine din:

Surse curate pentru plugin-uri și teme
Audit periodic manual al fișierelor
Monitorizare trafic de rețea
Hardening server-side (CloudLinux CageFS, ModSecurity custom)

3. Monitorizarea traficului contează mai mult decât crezi

Acest backdoor WordPress a fost detectat nu de scaner, ci de o alertă de trafic anormal. Dacă nu monitorizezi conexiunile outbound ale serverului tău, un atacator poate exfiltra date luni de zile fără să observi.

4. Backup-ul forensic salvează zile de muncă

Tentația după descoperirea unui incident este să „cureți și să mergi mai departe”. Greșeală. Salvează tot înainte de cleanup — vei avea nevoie pentru investigația vectorului de intrare, pentru raportare către autorități (în caz de breach de date personale, GDPR cere asta), și pentru a învăța din incident.

5. Asumă compromis total, nu doar parțial

Când găsești un backdoor WordPress pe un site, asumă că TOT ce era pe acel cont este compromis. Toate parolele, toate fișierele, toate conturile. Schimbă tot, regenerează tot, verifică tot. Atacatorii lasă adesea multiple backdoors ca persistență — eliminarea unuia singur nu te salvează.

Cum să te protejezi: checklist concret pentru site-ul tău

Înainte de a închide acest articol, verifică acum pe site-ul tău WordPress:

✅ Lista plugin-urilor: verifică în wp-admin → Plugin-uri. Recunoști fiecare nume? Ai instalat tu fiecare plugin? Dacă vezi ceva ce nu recunoști, caută numele exact pe wordpress.org. Dacă nu există acolo, este suspect.
✅ Sursa plugin-urilor: ai vreun plugin descărcat dintr-o sursă în afara wordpress.org sau a vendorului oficial? Dacă da, dezinstalează-l acum și înlocuiește cu licența oficială.
✅ Conturi admin: wp-admin → Utilizatori → Toți. Vezi doar conturile pe care le recunoști? Caută cu atenție conturi „admin”, „test”, „support”, „wpsupport” pe care nu le-ai creat tu.
✅ Fișiere PHP în uploads: verifică /wp-content/uploads/ — NU ar trebui să existe niciun fișier .php acolo. Dacă găsești, este aproape sigur malițios.
✅ Cron jobs WordPress: poți verifica cu plugin-ul „WP Crontrol” (gratuit, oficial). Vezi sarcini programate cu nume ciudate sau funcții pe care nu le recunoști? Investighează.
✅ Trafic outbound anormal: dacă ai acces SSH la server, rulează netstat -anp și vezi conexiunile active. Mergi vreundeva ce nu pare normal (IP-uri necunoscute, porturi neobișnuite)?
✅ Backup recent verificat: ai un backup făcut înainte de orice posibilă infectare, păstrat în afara serverului? Dacă nu, fă-l acum.
✅ Audit de securitate profesional: dacă vezi orice indiciu suspicios sau pur și simplu vrei liniște, cere o analiză SEO gratuită Web365 care include și o verificare de bază a integrității site-ului. Pentru audit complet de securitate, vezi serviciul de Securitate WordPress.

De ce povestim asta

Industriile de hosting și securitate au tradiția să țină incidente ca acestea sub tăcere. „Nu vorbim, ca să nu speriem clienții.”

Web365 are altă filozofie. Credem că transparența construiește încredere, iar lecțiile învățate din incidente reale ajută întreaga comunitate WordPress din România să fie mai în siguranță. Acest articol nu este reclamă — este experiență trăită, împărtășită ca să te protejăm pe tine de o situație similară.

Dacă administrezi un site WordPress și ai întrebări despre securitatea lui, scrie-ne. Suntem aici. 0727.299.999, [email protected], sau direct prin formularul de pe site.

Nu ești sigur ce plan de găzduire web să alegi?

Sună-ne sau scrie-ne pe WhatsApp. Îți recomandăm cinstit ce ți se potrivește — nu cel mai scump plan, ci cel corect pentru site-ul tău.

📞 0727.299.999 💬 WhatsApp

Întrebări frecvente

Cum verifică Web365 site-urile clienților pentru backdoors similare?

Echipa Web365 folosește o combinație de instrumente automate (Imunify360, ClamAV, ModSecurity cu reguli OWASP custom) și verificări manuale periodice pentru conturile cu activitate suspectă. Pentru clienții cu serviciul Securitate WordPress, facem audit lunar al integrității fișierelor core, scanare extinsă a plugin-urilor și temei, plus monitorizare trafic outbound.

Cu 11 ani de experiență și 19.000 site-uri găzduite, am dezvoltat pattern-uri proprii de detectare care complementează scanerele standard.

Pot avea un backdoor pe site-ul meu fără să știu?

Da, și asta este partea cea mai îngrijorătoare. Backdoors moderne sunt scrise să fie invizibile pentru utilizatorul normal — nu modifică aspectul vizibil al site-ului, nu generează erori, nu blochează funcționalitatea. Adesea singurele indicii sunt: trafic outbound crescut, creștere ușoară a consumului CPU/RAM, fișiere nou create pe care nu le recunoști. Recomandăm audit periodic al integrității site-ului — pentru clienții Web365 acesta este inclus în pachetele Securitate WordPress.

Ce ar trebui să fac dacă bănuiesc că site-ul meu este infectat?

Pașii imediați:
(1) NU șterge nimic încă — pierzi forensic evidence;
(2) schimbă parola contului cPanel și WordPress admin de pe un alt device, NU din site-ul afectat;
(3) fă un backup complet al stării actuale;
(4) contactează echipa de securitate (la Web365 prin 0727.299.999 sau tichet în clienti.web365.ro).
Cu cât intervii mai rapid, cu atât minimizezi daunele — exfiltrarea de date și pivot-ul lateral către alte sisteme se întâmplă în primele 24-72 ore de la compromis.

De ce nu detectează scanerele antivirus toate backdoors-urile?

Scanerele moderne sunt bune pentru malware clasic — cod obfuscat evident, semnături cunoscute, comportament tipic la runtime. Dar atacatorii profesioniști scriu cod care evită aceste pattern-uri: criptare standard (AES-256), structuri de plugin valide WordPress, funcționalitate aparent legitimă în paralel cu backdoor-ul. Singura apărare reală este combinația dintre scanere automate, audit manual periodic, monitorizare trafic și surse verificate pentru tot ce instalezi.

Cât costă curățarea unui site WordPress infectat?

Depinde de extinderea infectării și complexitatea site-ului. Pentru un site simplu cu o singură infectare evidentă, curățarea poate dura 2-4 ore și costul este moderat. Pentru un site major compromis cu multiple backdoors, exfiltrare de date și necesitatea audit complet, intervenția poate dura zile și costă proporțional. Web365 oferă cleanup gratuit de bază pentru clienții noștri activi, cu opțiunea de audit complet de securitate pentru cazuri severe.

Sună la 0727.299.999 pentru o estimare personalizată.

Cum mă protejez în viitor după o infectare?

Hardening complet post-incident: schimbare TOATE parolele (cPanel, WordPress, FTP, DB), regenerare salts WordPress, activare 2FA pe toate conturile admin, eliminare plugin-uri și teme nullate sau din surse neverificate, instalare WAF (la Web365 ModSecurity cu reguli OWASP custom este standard), monitorizare integritate fișiere lunară, backup zilnic în afara serverului, audit profesional periodic.

Pentru clienții care vor pace de mâine pe partea de securitate, serviciul Securitate WordPress Web365 cuprinde toate aceste componente într-un singur abonament.

Plugin-urile gratuite din wp-admin sunt sigure?

Plugin-urile din repository-ul oficial wordpress.org sunt verificate manual de echipa WordPress.org și automat de scanere de securitate. Sunt — în general — sigure. Riscul vine de la plugin-uri descărcate din ALTE surse: site-uri care oferă Pro gratis, forumuri obscure, link-uri din emailuri de spam. Aceste plugin-uri pot conține backdoor-uri ascunse, exact ca în cazul din articol.

Regula simplă: instalează DOAR din wp-admin → Plugin-uri → Adaugă nou (care folosește repository oficial), sau direct de la vendor oficial cu licență plătită.

Articole conexe

Continuă educarea pe partea de securitate WordPress:

De ce 73% din site-urile WordPress sunt vulnerabile — statistici globale și ce să faci concret
Cum verifici dacă un hosting este cu adevărat performant — securitatea începe cu hosting-ul
Cum migrezi un site WordPress fără downtime — dacă ești pe hosting compromis
Cât costă un site web în 2026 — include costul real al securității
Găzduire web România vs Europa — infrastructura contează

Servicii Web365 dedicate:

Securitate WordPress — audit complet, hardening, monitorizare
Optimizare WordPress — performanță și siguranță
Analiză SEO gratuită — include verificări de bază integritate

Surse și referințe tehnice

Patchstack — WordPress Security Threat Landscape Report
WordPress.org — Plugin Repository Guidelines
OWASP Foundation — Top 10 Web Application Security Risks
Sucuri — Hacked Website Report (statistici anuale)
NIST — Cybersecurity Framework for Incident Response