Pe scurt: Recunoașteți un webshell după fișierele PHP noi sau modificate în locuri atipice, după procesele străine ale utilizatorului serverului web și după conexiunile neobișnuite. Salvați urmele înainte de a șterge ceva și restabiliți codul dintr-o sursă curată. Un patch singur nu elimină o ușă din spate.
De ce sunt webshell-urile un subiect după PHP2Shell
Vulnerabilitățile CVE-2026-109618 și CVE-2026-109619 din PHP însuși permit executarea de cod malițios de la distanță, fără autentificare. O țintă evidentă după un atac reușit este o ușă din spate permanentă, deci un webshell. Aceasta rămâne chiar dacă între timp PHP a fost actualizat.
Potrivit rapoartelor din presă, o primă tentativă de atac a fost observată deja la 17.10.2026, iar patchurile au urmat la 21.10. Cine a fost vulnerabil în acest interval ar trebui să verifice țintit. Indicators of Compromise confirmați nu au fost publicați până acum. Căutarea se bazează de aceea pe abateri de comportament, nu pe o listă gata făcută.
Dacă găsiți un webshell pe un server cu date ale clienților: nu ștergeți în pripă. Mai întâi salvați dovezile, apoi izolați serverul și planificați prelucrarea ulterioară.
Cum recunoașteți un webshell: verificarea fișierelor
Majoritatea webshell-urilor sunt fișiere PHP din directorul web. Sunt suspecte fișierele apărute sau modificate după 17.10, fișierele PHP din dosarele de încărcare și de cache, precum și fișierele cu cod ofuscat. Comenzile următoare nu modifică nimic, doar listează:
# Fișiere PHP modificate de la 17.10.2026
find /var/www -type f -name "*.php*" -newermt "2026-10-17" -ls
# Fișiere PHP în dosare de încărcare, cache sau tmp
find /var/www -type f -name "*.php*" \( -path "*upload*" -o -path "*cache*" -o -path "*tmp*" \) -ls
# Ofuscare tipică: eval combinat cu decodare
grep -rlE "eval\s*\(\s*(base64_decode|gzinflate|str_rot13|gzuncompress)" /var/www --include="*.php"
# Liniile neobișnuit de lungi indică adesea cod împachetat
grep -rlE ".{3000,}" /var/www --include="*.php"
Rezultatele sunt indicii, nu dovezi. Unele pluginuri folosesc legitim cod codificat. Comparați fișierele suspecte cu pachetul original al producătorului. Cel mai sigur este o comparație cu sume de control sau cu un sistem de control al versiunilor precum Git:
# Abateri față de ultima stare cunoscută din depozitul Git
git -C /var/www/projekt status --porcelain
O marcă de timp poate fi falsificată. Nu vă bazați de aceea doar pe data modificării unui fișier.
Ce trăsături fac un fișier suspect
| Trăsătură | De ce atrage atenția |
|---|---|
| Fișier PHP într-un dosar de încărcare sau de imagini | Acolo ar trebui să existe doar fișiere media |
Extensie dublă precum .jpg.php sau .php.png |
Camuflare ca fișier inofensiv |
| Linii foarte lungi, fără rupere | Tipic pentru cod împachetat sau criptat |
| Nume de fișier asemănător unui fișier de bază, dar absent din pachetul original | Camuflare într-un mediu cunoscut |
| Proprietarul sau drepturile diferă de cele ale fișierelor vecine | Fișierul a fost creat pe altă cale |
Cu cât se adună mai multe trăsături, cu atât crește probabilitatea unei descoperiri. Deschideți fișierele suspecte doar ca text, niciodată prin browser, deoarece accesarea prin site ar executa codul.
Verificarea proceselor, conexiunilor și cronjoburilor
Un webshell activ lasă adesea urme și în afara sistemului de fișiere. Utilizatorul serverului web, de exemplu www-data, apache sau nginx, nu pornește în mod normal shelluri, instrumente de rețea sau compilatoare.
# Procesele utilizatorilor tipici ai serverului web
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx)"
# Conexiuni de rețea deschise, cu procesul aferent
sudo ss -tunap | grep -E "php|www-data|apache|nginx"
# Sarcinile programate ale utilizatorului serverului web
sudo crontab -u www-data -l
ls -la /etc/cron.d /var/spool/cron 2>/dev/null
Sunt suspecte conexiunile ieșite permanente către destinații necunoscute, procesele cu nume criptice și cronjoburile care descarcă fișiere de pe internet. Verificați, de asemenea, logurile de acces pentru cereri către fișiere care nu existau înainte. Cum se procedează descrie ghidul Cum analizați logurile serverului web după un atac.
Salvați urmele înainte de a elimina
Cine șterge primul pierde răspunsul la cele mai importante întrebări: cum a intrat atacatorul, ce a văzut, ce date sunt afectate? Aveți nevoie de aceste răspunsuri pentru o eventuală notificare RGPD, pentru asigurători și pentru decizia dacă alte sisteme sunt în pericol.
Ordine sensibilă:
- Documentați starea: lista proceselor, conexiunile de rețea, utilizatorii conectați.
- Copiați fișierele suspecte și logurile cu sumă de control, fără a le deschide sau executa.
- Dacă este posibil, creați o imagine a sistemului sau un snapshot al mașinii virtuale.
- Scoateți serverul din rețea sau restrângeți puternic accesul.
La sistemele cu date sensibile sau cu un posibil litigiu, salvarea ar trebui să se facă corect din punct de vedere criminalistic. Detalii găsiți la Criminalistică IT după un atac asupra serverului web.
Eliminarea corectă a webshell-urilor
Ștergerea unui singur fișier este rareori sfârșitul. Atacatorii creează adesea mai multe accesuri: alte fișiere în locuri ascunse, intrări în fișiere de configurare precum .htaccess sau .user.ini, conturi noi de administrator în aplicație sau cronjoburi. O curățare fiabilă urmează acești pași:
- Aduceți PHP la o versiune corectată (8.5.12, 8.4.27, 8.3.36, 8.2.35 sau backport confirmat) și reporniți toate procesele PHP.
- Reinstalați codul aplicației dintr-o sursă curată, în loc să reparați fișiere individuale.
- Preluați doar conținut verificat, precum încărcările și baza de date, și căutați acolo țintit cod introdus.
- Schimbați toate datele de acces: baza de date, SSH, FTP, conturi de administrator, chei API.
- Limitați drepturile de scriere ale serverului web la strictul necesar și împiedicați execuția PHP în dosarele de încărcare.
Pentru WordPress există ascunzători tipice proprii, descrise în ghidul Cum găsiți ușile din spate în WordPress. După aceea, site-ul ar trebui monitorizat mai atent o perioadă, pentru a observa din timp un nou acces.
Cum ajută PHP SOS concret?
- Salvăm logurile, fișierele și starea sistemului într-un mod verificabil, înainte de a modifica ceva.
- Căutăm uși din spate în fișiere, baza de date, cronjoburi și configurare și încadrăm descoperirile.
- Reinstalăm aplicația dintr-o sursă curată, schimbăm accesurile și securizăm serverul.
- Documentăm incidentul până la închiderea lui, ca bază pentru notificări și asigurători.
Procesul unei curățări îl descrie serviciul Eliminarea malware-ului și a webshell-urilor.
Întrebări frecvente
Ce este un webshell?
Un webshell este un fișier introdus pe server, de obicei PHP, prin care atacatorii pot controla serverul de la distanță. Se camuflează adesea ca un fișier inofensiv, cu un nume banal, și rămâne activ chiar și după o actualizare.
Găsește un antivirus orice webshell?
Nu. Scannerele recunosc tipare cunoscute, variantele noi sau puternic ofuscate le scapă. Pentru PHP2Shell nu există nici Indicators of Compromise publicați și confirmați, de aceea analiza comportamentului contează mai mult decât o listă de semnături.
Este suficient să șterg fișierul găsit?
De regulă nu. Atacatorii creează adesea mai multe accesuri, de exemplu alte fișiere, cronjoburi sau conturi noi de administrator. Fără analiza cauzei și fără schimbarea tuturor datelor de acces, un nou acces este probabil.
Trebuie să raportez ceva după ce găsesc un webshell?
Dacă pot fi afectate date cu caracter personal, poate exista o obligație de notificare conform RGPD, de regulă în termen de 72 de ore. Clarificați acest lucru cu responsabilul dumneavoastră cu protecția datelor sau cu un avocat; aceasta nu este consultanță juridică.