Krótko: Webshell rozpozna się po nowych lub zmienionych plikach PHP w nietypowych miejscach, po obcych procesach użytkownika serwera WWW i po nietypowych połączeniach. Proszę zabezpieczyć ślady, zanim cokolwiek usuną, i odtworzyć kod z czystego źródła. Sama poprawka nie usuwa tylnej furtki.
Dlaczego webshelle są tematem po PHP2Shell
Luki CVE-2026-109618 i CVE-2026-109619 w samym PHP umożliwiają zdalne wykonanie złośliwego kodu bez logowania. Oczywistym celem po udanym ataku jest trwała tylna furtka, czyli webshell. Pozostaje ona także wtedy, gdy PHP zostało już zaktualizowane.
Według doniesień medialnych pierwszą próbę ataku zaobserwowano już 17.10.2026, a poprawki pojawiły się 21.10. Kto w tym okresie był podatny, powinien sprawdzić to celowo. Potwierdzone wskaźniki naruszenia nie zostały dotąd opublikowane. Poszukiwania opierają się więc na nietypowym zachowaniu, a nie na gotowej liście.
Jeśli znajdą Państwo webshell na serwerze z danymi klientów: niczego nie usuwać pochopnie. Najpierw zabezpieczyć dowody, potem odizolować serwer i zaplanować dalsze postępowanie.
Jak rozpoznać webshell: sprawdzanie plików
Większość webshelli to pliki PHP w katalogu WWW. Podejrzane są pliki utworzone lub zmienione po 17.10., pliki PHP w folderach uploadu i pamięci podręcznej oraz pliki z zaciemnionym kodem. Poniższe polecenia niczego nie zmieniają, tylko wypisują:
# Pliki PHP zmienione od 17.10.2026
find /var/www -type f -name "*.php*" -newermt "2026-10-17" -ls
# Pliki PHP w folderach uploadu, pamięci podręcznej lub tmp
find /var/www -type f -name "*.php*" \( -path "*upload*" -o -path "*cache*" -o -path "*tmp*" \) -ls
# Typowe zaciemnianie: eval w połączeniu z dekodowaniem
grep -rlE "eval\s*\(\s*(base64_decode|gzinflate|str_rot13|gzuncompress)" /var/www --include="*.php"
# Nietypowo długie wiersze często wskazują na spakowany kod
grep -rlE ".{3000,}" /var/www --include="*.php"
Trafienia są wskazówkami, nie dowodami. Niektóre wtyczki zgodnie z zasadami używają zakodowanego kodu. Podejrzane pliki proszę porównać z oryginalnym pakietem producenta. Najbardziej wiarygodne jest porównanie z sumami kontrolnymi lub z systemem kontroli wersji, takim jak Git:
# Odchylenia od ostatniego znanego stanu w repozytorium Git
git -C /var/www/projekt status --porcelain
Znacznik czasu można sfałszować. Dlatego nie należy polegać wyłącznie na dacie zmiany pliku.
Jakie cechy czynią plik podejrzanym
| Cecha | Dlaczego zwraca uwagę |
|---|---|
| Plik PHP w folderze uploadu lub obrazów | Powinny tam leżeć tylko media |
Podwójne rozszerzenie, takie jak .jpg.php lub .php.png |
Kamuflaż jako niewinny plik |
| Bardzo długie wiersze bez podziału | Typowe dla spakowanego lub zaszyfrowanego kodu |
| Nazwa pliku podobna do pliku rdzenia, ale nieobecna w oryginalnym pakiecie | Kamuflaż w znanym otoczeniu |
| Właściciel lub uprawnienia różnią się od sąsiednich plików | Plik został utworzony inną drogą |
Im więcej cech się zbiega, tym większe prawdopodobieństwo znaleziska. Podejrzane pliki proszę otwierać tylko jako tekst, nigdy przez przeglądarkę, ponieważ wywołanie przez stronę wykonałoby kod.
Sprawdzanie procesów, połączeń i zadań cron
Aktywny webshell często zostawia ślady poza systemem plików. Użytkownik serwera WWW, na przykład www-data, apache lub nginx, zwykle nie uruchamia powłok, narzędzi sieciowych ani kompilatorów.
# Procesy typowych użytkowników serwera WWW
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx)"
# Otwarte połączenia sieciowe wraz z procesem
sudo ss -tunap | grep -E "php|www-data|apache|nginx"
# Zaplanowane zadania użytkownika serwera WWW
sudo crontab -u www-data -l
ls -la /etc/cron.d /var/spool/cron 2>/dev/null
Podejrzane są trwałe połączenia wychodzące do nieznanych celów, procesy o zagadkowych nazwach i zadania cron, które pobierają pliki z internetu. Proszę sprawdzić też logi dostępu pod kątem żądań do plików, których wcześniej nie było. Jak to zrobić, opisuje poradnik Analiza logów serwera WWW po ataku.
Zabezpieczenie śladów przed usunięciem
Kto najpierw usuwa, traci odpowiedź na najważniejsze pytania: jak atakujący się dostał, co zobaczył, jakie dane zostały dotknięte? Te odpowiedzi są potrzebne do ewentualnego zgłoszenia na podstawie RODO, dla ubezpieczycieli i do decyzji, czy zagrożone są dalsze systemy.
Sensowna kolejność:
- Udokumentować stan: lista procesów, połączenia sieciowe, zalogowani użytkownicy.
- Skopiować podejrzane pliki i logi z sumą kontrolną, bez otwierania i uruchamiania.
- Jeśli to możliwe, utworzyć obraz systemu lub migawkę (snapshot) maszyny wirtualnej.
- Odłączyć serwer od sieci lub mocno ograniczyć dostęp.
W systemach z danymi wrażliwymi lub przy możliwym sporze prawnym zabezpieczenie powinno przebiegać w sposób czysty z punktu widzenia informatyki śledczej. Tło znajdą Państwo na stronie Informatyka śledcza po ataku na serwer WWW.
Czyste usuwanie webshelli
Usunięcie pojedynczego pliku rzadko kończy sprawę. Atakujący często zakładają kilka dostępów: dalsze pliki w ukrytych miejscach, wpisy w plikach konfiguracyjnych takich jak .htaccess lub .user.ini, nowe konta administratorów w aplikacji lub zadania cron. Rzetelne oczyszczenie przebiega według tych kroków:
- Doprowadzić PHP do naprawionego stanu (8.5.12, 8.4.27, 8.3.36, 8.2.35 lub potwierdzony backport) i zrestartować wszystkie procesy PHP.
- Postawić kod aplikacji od nowa z czystego źródła zamiast naprawiać pojedyncze pliki.
- Przejmować tylko sprawdzone zawartości, takie jak uploady i baza danych, i szukać tam celowo wprowadzonego kodu.
- Zmienić wszystkie dane dostępowe: baza danych, SSH, FTP, konta administratorów, klucze API.
- Ograniczyć uprawnienia zapisu serwera WWW do niezbędnego minimum i zablokować wykonywanie PHP w folderach uploadu.
Dla WordPressa istnieją własne typowe kryjówki, które opisuje poradnik Jak znaleźć tylne furtki w WordPressie. Potem stronę należy przez pewien czas ściślej monitorować, aby wcześnie zauważyć ponowny dostęp.
Jak konkretnie pomaga PHP SOS?
- Zabezpieczamy logi, pliki i stan systemu w sposób możliwy do prześledzenia, zanim cokolwiek zostanie zmienione.
- Szukamy tylnych furtek w plikach, bazie danych, zadaniach cron i konfiguracji oraz klasyfikujemy znaleziska.
- Stawiamy aplikację od nowa z czystego źródła, zmieniamy dostępy i utwardzamy serwer.
- Dokumentujemy incydent aż do jego zamknięcia, jako podstawę zgłoszeń i dla ubezpieczycieli.
Przebieg oczyszczania opisuje usługa Usuwanie malware i webshelli.
Częste pytania
Czym jest webshell?
Webshell to wprowadzony przez atakującego plik, zwykle PHP, za pomocą którego można zdalnie sterować serwerem. Często ukrywa się jako niewinny plik o niepozornej nazwie i pozostaje aktywny także po aktualizacji.
Czy skaner antywirusowy znajdzie każdy webshell?
Nie. Skanery rozpoznają znane wzorce, nowe lub silnie zaciemnione warianty prześlizgują się niezauważone. Dla PHP2Shell nie opublikowano ponadto potwierdzonych wskaźników naruszenia (Indicators of Compromise), dlatego analiza zachowania jest ważniejsza niż lista sygnatur.
Czy wystarczy usunąć znaleziony plik?
Zwykle nie. Atakujący często zakładają kilka dostępów, na przykład dodatkowe pliki, zadania cron lub nowe konta administratorów. Bez analizy przyczyny i zmiany wszystkich danych dostępowych ponowny dostęp jest prawdopodobny.
Czy po znalezieniu webshella muszę coś zgłosić?
Jeśli mogą być dotknięte dane osobowe, może istnieć obowiązek zgłoszenia na podstawie RODO, co do zasady w ciągu 72 godzin. Proszę to wyjaśnić z inspektorem ochrony danych lub prawnikiem; nie jest to porada prawna.