Pe scurt: Dacă un server a fost hackuit prin PHP2Shell nu se poate citi dintr-o singură trăsătură. Nu există Indicators of Compromise publicați și confirmați; detecția se bazează pe analiza comportamentului. Semne tipice sunt fișierele PHP noi, cronjoburile necunoscute și conexiunile neobișnuite. Salvați mai întâi logurile începând cu 20 octombrie, înainte de a modifica ceva.
Există semne clare ale unui atac PHP2Shell?
Nu, și acesta este răspunsul sincer. Pentru multe vulnerabilități cunoscute, producătorii sau firmele de securitate publică urme concrete: nume de fișiere, sume de control, adrese IP. Pentru PHP2Shell asemenea Indicators of Compromise confirmați nu există deocamdată.
Ce se știe: potrivit rapoartelor din presă, o primă tentativă de atac a fost observată la 17 octombrie, patru zile înainte de patchurile din 21 octombrie. Cloudflare a raportat alte tentative. Atacuri reușite confirmate, la scară largă, nu erau cunoscute inițial, potrivit BSI (Oficiul Federal German pentru Securitatea Informațiilor). Cine a fost accesibil fără protecție între 17 octombrie și propriul patch ar trebui, de aceea, să verifice, nu să spere.
Pentru evaluare contează mai ales perioada. Între prima tentativă de atac observată, la 17 octombrie, și patchurile din 21 octombrie nu a existat nicio actualizare oficială. Orice server PHP accesibil public a fost în acest interval potențial atacabil. Cât timp a fost serverul dumneavoastră deschis dincolo de aceasta depinde de momentul în care a fost aplicată actualizarea și PHP a fost repornit. Cu cât această perioadă este mai lungă și cu cât datele sunt mai sensibile, de exemplu conturi de clienți, comenzi sau candidaturi, cu atât verificarea ar trebui să fie mai temeinică.
Semne tipice că un server a fost hackuit
După o execuție reușită de cod, atacatorii încearcă de regulă să se instaleze și să folosească serverul. Rezultă semne care nu sunt specifice PHP2Shell, dar contează la orice verificare a unei intruziuni:
- Fișiere PHP noi sau modificate, mai ales în dosarele de încărcare, de cache sau de imagini, unde în mod normal nu se află fișiere PHP.
- Cronjoburi necunoscute sau sarcini programate, de exemplu pentru utilizatorul serverului web.
- Conexiuni neobișnuite spre exterior către adrese necunoscute, încărcare mare a rețelei sau trimitere de e-mailuri pe care nu le-a inițiat nimeni.
- Conturi noi de administrator în CMS sau în magazin, parole modificate, chei SSH necunoscute.
- Încărcare vizibilă: utilizare mare și constantă a CPU de către procese necunoscute, adesea un indiciu de minare de criptomonede.
- Consecințe vizibile: redirecționări către site-uri străine, pagini spam în indexul Google, avertismente în browser sau în Search Console.
Niciunul dintre aceste semne nu dovedește singur o intruziune, iar absența lor nu dovedește contrariul. Decisiv este tabloul de ansamblu.
Primele verificări, fără a distruge urmele
Înainte de a șterge sau de a reporni ceva: salvați logurile. Presa de specialitate recomandă păstrarea logurilor serverului începând cu 20 octombrie. Copiați logurile serverului web, ale PHP și ale sistemului într-un loc sigur, în afara serverului.
Apoi ajută verificările strict de citire. Căile și numele de utilizator diferă de la un sistem la altul:
# Fișiere PHP modificate după 17.10.
find /var/www -type f -name "*.php" -newermt "2026-10-17" -ls
# fișiere PHP în directoarele de încărcare (exemplu WordPress)
find /var/www -path "*/uploads/*" -name "*.php" -ls
# Cronjob-urile utilizatorului serverului web și cele la nivel de sistem
crontab -l -u www-data
ls -la /etc/cron.d /etc/cron.daily /var/spool/cron 2>/dev/null
# conexiuni de rețea active, cu procesul aferent
ss -tunp
# letzte Anmeldungen
last -n 30
Rețineți: atacatorii pot falsifica marcajele de timp ale fișierelor. Un rezultat neinteresant al comenzii find nu este, de aceea, o achitare. Cum analizați logurile țintit descrie Cum analizați logurile serverului web după un atac; cum găsiți ușile dosnice, Cum recunoașteți și eliminați webshell-urile.
Dacă găsiți indicii concrete, de exemplu un fișier PHP necunoscut în dosarul de încărcare: nu îl ștergeți, nu reinstalați, nu „reparați rapid” aplicația. Deconectați sau izolați serverul, salvați logurile și imaginea sistemului și începeți o tratare structurată a incidentului.
Ce nu ar trebui să faceți
- Să aplicați doar patchul și să mergeți mai departe. Un patch nu elimină software-ul malițios deja introdus.
- Să ștergeți imediat fișierele suspecte. Astfel dispar dovezile despre ce s-a întâmplat și ce date pot fi afectate.
- Să reinstalați serverul înainte de a salva. Cauza rămâne neclară, iar o ușă dosnică din baza de date sau din datele de acces supraviețuiește reinstalării.
- Să restaurați backupuri vechi fără verificare. Și un backup poate conține deja ușa dosnică.
- Să uitați datele de acces. După o execuție de cod, parolele bazelor de date, cheile API și alte date de acces din fișierele de configurare pot fi exfiltrate. Reînnoiți-le după curățare, nu înainte, pentru ca un atacator încă activ să nu le citească imediat și pe cele noi.
Dacă suspiciunea se confirmă
Atunci este vorba de mai mult decât tehnică. Verificați împreună cu responsabilul dumneavoastră cu protecția datelor dacă este necesară o notificare conform RGPD; termenul este de 72 de ore de la luarea la cunoștință, detalii la Obligația de notificare conform RGPD. Informați din timp asigurătorul dumneavoastră cyber, dacă există, și clarificați cu un avocat dacă trebuie depusă o sesizare. Noi oferim indicații generale, nu consultanță juridică.
Cum ajută PHP SOS concret?
Prin Incident Response parcurgem o suspiciune în mod structurat:
- Salvare: loguri începând cu 20 octombrie și, unde este necesar, o imagine a sistemului, înainte de a modifica ceva.
- Investigare: analiza comportamentului fișierelor, proceselor, conexiunilor și conturilor; la nevoie, cu valoare în fața instanței, prin criminalistică IT.
- Curățare și închidere: eliminarea ușilor dosnice, actualizarea PHP, reînnoirea datelor de acces, securizarea serverului.
- Documentare, până când incidentul este încheiat și documentat, ca bază pentru protecția datelor, asigurare și conducere.
Întrebări frecvente
Dovedește actualizarea PHP că serverul meu este curat?
Nu. Un patch închide vulnerabilitatea pentru viitor, dar nu elimină software-ul malițios deja introdus. Nici nu spune nimic despre dacă înainte de patch a pătruns cineva.
Există un scanner care recunoaște sigur atacurile PHP2Shell?
Până acum nu. Nu există Indicators of Compromise publicați și confirmați după care un scanner să poată căuta țintit. Scannerele de malware găsesc webshell-uri cunoscute, dar evaluarea unui server se bazează pe analiza comportamentului.
Trebuie să raportez o suspiciune autorității pentru protecția datelor?
Depinde dacă pot fi afectate date cu caracter personal. RGPD prevede pentru încălcările de securitate care trebuie notificate un termen de 72 de ore de la luarea la cunoștință. Clarificați acest lucru din timp cu responsabilul dumneavoastră cu protecția datelor sau cu un avocat; noi nu oferim consultanță juridică.
Ar trebui să reinstalez pur și simplu serverul hackuit?
Nu ca prim pas. Salvați mai întâi logurile și, dacă este posibil, o imagine a sistemului. Cine reinstalează imediat pierde urmele care arată ce s-a întâmplat și ce date ar putea fi afectate.