Ukratko: Je li poslužitelj hakiran putem PHP2Shella, ne može se očitati po jednom obilježju. Ne postoje objavljeni, potvrđeni indikatori kompromitacije (Indicators of Compromise); otkrivanje počiva na analizi ponašanja. Tipični znakovi su nove PHP datoteke, nepoznati cron poslovi i neuobičajene veze. Prvo osigurajte zapisnike od 20. listopada prije nego što išta promijenite.
Postoje li nedvosmisleni znakovi PHP2Shell napada?
Ne, i to je iskren odgovor. Za mnoge poznate ranjivosti proizvođači ili sigurnosne tvrtke objavljuju konkretne tragove: nazive datoteka, kontrolne zbrojeve, IP adrese. Za PHP2Shell takvih potvrđenih indikatora kompromitacije za sada nema.
Što je poznato: prema medijskim izvješćima prvi je pokušaj napada uočen 17. listopada, četiri dana prije zakrpa od 21. listopada. Cloudflare je prijavio daljnje pokušaje. Potvrđeni uspješni napadi u širem opsegu prema BSI-ju (njemački Savezni ured za sigurnost informacijske tehnologije) isprva nisu bili poznati. Tko je između 17. listopada i vlastite zakrpe bio nezaštićeno dostupan, trebao bi stoga provjeriti umjesto se nadati.
Za procjenu je prije svega važno razdoblje. Između prvog uočenog pokušaja napada 17. listopada i zakrpa 21. listopada nije bilo službenog ažuriranja. Svaki javno dostupan PHP poslužitelj u tom je razdoblju potencijalno bio ranjiv. Koliko je Vaš poslužitelj bio otvoren i dulje, ovisi o tome kada je ažuriranje instalirano i PHP ponovno pokrenut. Što je to razdoblje dulje i što su podaci osjetljiviji, primjerice korisnički računi, narudžbe ili prijave za posao, to temeljitije treba biti provjera.
Tipični znakovi da je poslužitelj hakiran
Nakon uspješnog izvršavanja koda napadači se obično nastoje učvrstiti i iskoristiti poslužitelj. Iz toga proizlaze znakovi koji nisu specifični za PHP2Shell, ali vrijede za svaku provjeru provale:
- Nove ili izmijenjene PHP datoteke, osobito u mapama za prijenos, predmemoriju ili slike u kojima inače nema PHP datoteka.
- Nepoznati cron poslovi ili planirani zadaci, primjerice za korisnika web-poslužitelja.
- Neuobičajene odlazne veze prema nepoznatim adresama, veliko opterećenje mreže ili slanje e-pošte koje nitko nije pokrenuo.
- Novi administratorski računi u CMS-u ili shopu, promijenjene lozinke, nepoznati SSH ključevi.
- Upadljivo opterećenje: trajno visoko opterećenje procesora nepoznatim procesima, često naznaka kripto rudarenja.
- Vidljive posljedice: preusmjeravanja na strane stranice, spam stranice u Googleovu indeksu, upozorenja u pregledniku ili u Search Consoleu.
Nijedan od tih znakova sam po sebi ne dokazuje provalu, a njihov izostanak ne dokazuje suprotno. Odlučujuća je cjelokupna slika.
Prve provjere bez uništavanja tragova
Prije nego što išta obrišete ili ponovno pokrenete: osigurajte zapisnike. Stručni tisak savjetuje čuvanje zapisnika poslužitelja od 20. listopada. Kopirajte zapisnike web-poslužitelja, PHP-a i sustava na sigurno mjesto izvan poslužitelja.
Zatim pomažu isključivo čitajuće provjere. Putanje i korisnička imena razlikuju se po sustavu:
# PHP datoteke izmijenjene od 17. 10.
find /var/www -type f -name "*.php" -newermt "2026-10-17" -ls
# PHP datoteke u direktorijima za učitavanje (primjer WordPress)
find /var/www -path "*/uploads/*" -name "*.php" -ls
# Cron poslovi korisnika web-poslužitelja i na razini sustava
crontab -l -u www-data
ls -la /etc/cron.d /etc/cron.daily /var/spool/cron 2>/dev/null
# aktivne mrežne veze s procesom
ss -tunp
# letzte Anmeldungen
last -n 30
Imajte na umu: napadači mogu krivotvoriti vremenske oznake datoteka. Neupadljiv rezultat naredbe find stoga nije oslobađajuća presuda. Kako ciljano analizirati zapisnike, opisuje Analiza zapisnika web-poslužitelja nakon napada; kako pronaći stražnja vrata, Prepoznavanje i uklanjanje web shellova.
Ako pronađete konkretne naznake, primjerice nepoznatu PHP datoteku u mapi za prijenos: ne brišite, ne postavljajte iznova, ne „popravljajte brzo“ aplikaciju. Odvojite ili izolirajte poslužitelj s mreže, osigurajte zapisnike i sliku sustava te započnite strukturiranu obradu incidenta.
Što ne biste trebali činiti
- Samo zakrpati i nastaviti. Zakrpa ne uklanja već ubačeni zlonamjerni softver.
- Odmah brisati sumnjive datoteke. Tako nestaju dokazi o tome što se dogodilo i koji bi podaci mogli biti pogođeni.
- Postaviti poslužitelj iznova prije nego što je osiguran. Uzrok ostaje nejasan, a stražnja vrata u bazi podataka ili pristupni podaci prežive novu instalaciju.
- Vraćati stare sigurnosne kopije neprovjereno. I sigurnosna kopija može već sadržavati stražnja vrata.
- Zaboraviti pristupne podatke. Nakon izvršavanja koda mogle su odliti lozinke baza podataka, API ključevi i drugi pristupni podaci iz konfiguracijskih datoteka. Obnovite ih nakon čišćenja, a ne prije, kako ih napadač koji je još aktivan ne bi odmah pročitao.
Ako se sumnja potvrdi
Tada je riječ o više od tehnike. Sa službenikom za zaštitu podataka provjerite je li potrebna prijava prema GDPR-u; rok je 72 sata od saznanja, pojedinosti na stranici Obveza prijave prema GDPR-u. Rano obavijestite svog osiguravatelja za cyber rizike, ako postoji, i s odvjetnikom razjasnite treba li podnijeti prijavu. Mi za to dajemo opće napomene, a ne pravno savjetovanje.
Kako PHP SOS konkretno pomaže?
Uz naš Incident Response sumnju obrađujemo strukturirano:
- Osigurati: zapisnike od 20. listopada i, gdje je potrebno, sliku sustava prije nego što se išta promijeni.
- Istražiti: analiza ponašanja datoteka, procesa, veza i računa; po potrebi s dokaznom vrijednošću na sudu putem IT forenzike.
- Očistiti i zatvoriti: ukloniti stražnja vrata, ažurirati PHP, obnoviti pristupne podatke, ojačati poslužitelj.
- Dokumentirati, dok incident nije zaključen i dokumentiran, kao osnovu za zaštitu podataka, osiguranje i upravu.
Česta pitanja
Dokazuje li PHP ažuriranje da je moj poslužitelj čist?
Ne. Zakrpa zatvara ranjivost za budućnost, ali ne uklanja već ubačeni zlonamjerni softver. Ne govori ni je li netko upao prije zakrpe.
Postoji li skener koji pouzdano prepoznaje PHP2Shell napade?
Do sada ne. Ne postoje objavljeni, potvrđeni indikatori kompromitacije koje bi skener mogao ciljano tražiti. Skeneri malwarea pronalaze poznate web shellove, ali procjena poslužitelja počiva na analizi ponašanja.
Moram li sumnju prijaviti tijelu za zaštitu podataka?
To ovisi o tome mogu li biti pogođeni osobni podaci. GDPR za povrede podataka koje se moraju prijaviti predviđa rok od 72 sata od saznanja. Razjasnite to rano sa svojim službenikom za zaštitu podataka ili odvjetnikom; mi za to ne pružamo pravno savjetovanje.
Trebam li hakirani poslužitelj jednostavno postaviti iznova?
Ne kao prvi korak. Prvo osigurajte zapisnike i, ako je moguće, sliku sustava. Tko odmah postavlja iznova, gubi tragove koji pokazuju što se dogodilo i koji bi podaci mogli biti pogođeni.