1. Contextul problemei
Website-ul arkadus.ro prezenta o situație neobișnuită:
- Back-end (WordPress Admin): funcțional, accesul era posibil.
- Front-end: afișa doar o pagină albă (white screen of death), fără conținut, ceea ce indica o posibilă problemă de cod PHP injectat sau erori fatale ascunse.
Această diferență între funcționarea normală a panoului de administrare și nefuncționarea interfeței publice a ridicat suspiciunea unui atac sau a unui backdoor.
2. Pașii inițiali de diagnostic
1.Verificarea logurilor de server (error_log, access_log)
- Nu s-au găsit erori PHP clasice (ex. fatal errors), ceea ce sugera că problema nu era din codul nativ al temei sau pluginurilor.
- În access log apăreau cereri suspecte către fișiere inexistente sau către URL-uri externe.
2.Activarea WP_DEBUG și WP_DEBUG_LOG
- Chiar și cu debug activat, pagina albă persista fără mesaje de eroare afișate.
- Acest lucru este un indiciu clasic al unui cod malițios care interceptează execuția și nu returnează nimic.
3.Scanarea temei și a pluginurilor instalate
- S-a verificat dacă tema activă sau pluginurile conțin fișiere noi sau cod suspect.
- Rezultatul: tema și pluginurile nu conțineau modificări majore sau fișiere ascunse, ceea ce a dus la concluzia că problema era în altă parte.
4.Scanarea fișierelor cu grep și instrumente de securitate (Wordfence, Maldet, ClamAV)
- Căutarea după funcții suspecte precum base64_decode, eval, gzinflate, curl_exec, file_get_contents a scos la iveală un cod necunoscut în fișierul /home/arkadus/public_html/index.php.
3. Identificarea codului malițios
În urma scanării fișierelor, codul suspect a fost localizat în /home/arkadus/public_html/index.php – un fișier care, în mod normal, conține doar câteva linii pentru a porni WordPress. În acest caz, fișierul conținea un bloc consistent de cod necunoscut, organizat în mai multe funcții.
3.1 Funcțiile ascunse
- curl_get_contents, getServerCont, getSeCont11, getCont – toate aceste funcții erau variante ale unei metode de a trimite cereri cURL POST către un server extern, cu dezactivarea completă a verificărilor SSL (CURLOPT_SSL_VERIFYPEER, CURLOPT_SSL_VERIFYHOST).
- is_crawler și check_refer – verificau dacă vizitatorul era un crawler (Googlebot, Yahoo, Bing etc.) sau dacă provenea de pe un motor de căutare.
3.2 Serverul de comandă și control (C&C)
Un element cheie descoperit în cod a fost:
$a=’69.30.221.66/z50726_6/’;
$a=’http://’.$a;
Acest lucru arată clar că toate datele și cererile erau direcționate către IP-ul 69.30.221.66, un server extern controlat de atacator, situat în rețeaua Hosting Solutions International (în trecut asociat cu găzduiri utilizate pentru atacuri).
3.3 Datele transmise către serverul atacator
Codul crea un array $data1 care era trimis prin POST către serverul 69.30.221.66. Acest array conținea:
- domain – domeniul site-ului compromis (arkadus.ro).
- req_uri – adresa URL accesată de utilizator.
- href – linkul generat către pagina respectivă.
- req_url – adresa completă a cererii (protocol + domeniu + path).
- robots_cont – conținutul fișierului robots.txt citit local.
- word / action – parametri folosiți pentru manipularea sitemap-urilor.
- ip – adresa IP a vizitatorului.
- referer – site-ul de pe care a venit vizitatorul.
- user_agent – tipul de browser / crawler folosit.
- main_shell – adresa scriptului principal compromis (index.php).
Aceste informații ofereau atacatorului:
- Control asupra SEO – putea înlocui sitemap-urile și robots.txt pentru a direcționa Google către conținut fals.
- Date despre trafic – IP-uri reale, refereri, agenți user (utile pentru atacuri ulterioare sau pentru a evita detecția).
- Posibilitatea de redirecționare a vizitatorilor către pagini de phishing sau malware.
- Persistență – dacă administratorul ștergea doar parțial codul, atacatorul putea rescrie fișierele prin comenzile transmise de serverul extern.
3.4 Mecanismul de mască (cloaking)
Un aspect important al codului este că distingea între boți și vizitatori reali:
- Dacă vizitatorul era Googlebot sau venea dintr-un motor de căutare ⇒ i se afișa conținut injectat pentru SEO.
- Dacă era utilizator obișnuit, dar îndeplinea anumite condiții (check_refer + expresii regulate pe URL), era redirecționat către alte pagini prin jump.php.
- Dacă nu se îndeplineau condițiile ⇒ în multe cazuri nu se returna nimic, rezultând „pagina albă” observată.
4. Măsuri de remediere
- Ștergerea codului malițios și restaurarea fișierului index.php original.
- Scanare completă a public_html pentru alte fișiere infectate.
- Compararea fișierelor de core WordPress cu cele oficiale (wp core verify-checksums).
- Verificarea permisiunilor fișierelor și directoarelor.
- Resetarea tuturor parolelor (admin, FTP, cPanel, DB).
- Audit și actualizare pentru tema și pluginurile instalate.
- Instalarea unui plugin de securitate (Wordfence)
