Krótko: To, czy serwer został zhakowany przez PHP2Shell, nie wynika z pojedynczej cechy. Nie ma opublikowanych, potwierdzonych wskaźników naruszenia (Indicators of Compromise); wykrywanie opiera się na analizie zachowania. Typowe oznaki to nowe pliki PHP, nieznane zadania cron i nietypowe połączenia. Proszę najpierw zabezpieczyć logi od 20 października, zanim cokolwiek zmienią.
Czy istnieją jednoznaczne oznaki ataku PHP2Shell?
Nie, i jest to uczciwa odpowiedź. Dla wielu znanych luk producenci lub firmy zajmujące się bezpieczeństwem publikują konkretne ślady: nazwy plików, sumy kontrolne, adresy IP. Dla PHP2Shell takich potwierdzonych wskaźników naruszenia dotąd nie ma.
Co jest znane: według doniesień medialnych pierwszą próbę ataku zaobserwowano 17 października, cztery dni przed poprawkami z 21 października. Cloudflare zgłosił dalsze próby. Według BSI potwierdzone, udane ataki na szeroką skalę początkowo nie były znane. Kto między 17 października a własną poprawką był dostępny bez zabezpieczeń, powinien więc sprawdzić, zamiast mieć nadzieję.
Dla oceny liczy się przede wszystkim okres. Między pierwszą zaobserwowaną próbą ataku 17 października a poprawkami 21 października nie było oficjalnej aktualizacji. Każdy publicznie dostępny serwer PHP był w tym czasie potencjalnie podatny na atak. Jak długo Państwa serwer był otwarty dalej, zależy od tego, kiedy zainstalowano aktualizację i zrestartowano PHP. Im dłuższy ten okres i im wrażliwsze dane, na przykład konta klientów, zamówienia czy aplikacje, tym dokładniejsze powinno być sprawdzenie.
Typowe oznaki, że serwer został zhakowany
Po udanym wykonaniu kodu atakujący zwykle próbują się utrwalić i wykorzystać serwer. Wynikają z tego oznaki, które nie są specyficzne dla PHP2Shell, ale liczą się przy każdej kontroli włamania:
- Nowe lub zmienione pliki PHP, zwłaszcza w katalogach uploadów, pamięci podręcznej lub obrazów, w których zwykle nie leżą pliki PHP.
- Nieznane zadania cron lub zaplanowane zadania, na przykład dla użytkownika serwera WWW.
- Nietypowe połączenia wychodzące do nieznanych adresów, duże obciążenie sieci lub wysyłka poczty, której nikt nie zainicjował.
- Nowe konta administratorów w CMS lub sklepie, zmienione hasła, nieznane klucze SSH.
- Podejrzane obciążenie: stale wysokie wykorzystanie CPU przez nieznane procesy, często wskazówka kopania kryptowalut.
- Widoczne skutki: przekierowania na obce strony, strony ze spamem w indeksie Google, ostrzeżenia w przeglądarce lub w Search Console.
Żadna z tych oznak sama nie dowodzi włamania, a ich brak nie dowodzi czegoś przeciwnego. Decyduje całościowy obraz.
Pierwsze kontrole bez niszczenia śladów
Zanim cokolwiek usuną lub zrestartują: proszę zabezpieczyć logi. Prasa branżowa radzi zachować logi serwera od 20 października. Proszę skopiować logi serwera WWW, PHP i systemowe w bezpieczne miejsce poza serwerem.
Następnie pomagają kontrole wyłącznie odczytowe. Ścieżki i nazwy użytkowników różnią się zależnie od systemu:
# Pliki PHP zmienione od 17.10.
find /var/www -type f -name "*.php" -newermt "2026-10-17" -ls
# Pliki PHP w katalogach uploadów (przykład WordPress)
find /var/www -path "*/uploads/*" -name "*.php" -ls
# Zadania cron użytkownika serwera WWW i systemowe
crontab -l -u www-data
ls -la /etc/cron.d /etc/cron.daily /var/spool/cron 2>/dev/null
# aktywne połączenia sieciowe z procesem
ss -tunp
# ostatnie logowania
last -n 30
Proszę pamiętać: atakujący mogą fałszować znaczniki czasu plików. Niepodejrzany wynik find nie jest więc uniewinnieniem. Jak celowo analizować logi, opisuje strona Analiza logów serwera WWW po ataku; jak znajdować tylne furtki, strona Rozpoznawanie i usuwanie webshelli.
Jeśli znajdą Państwo konkretne wskazówki, na przykład nieznany plik PHP w folderze uploadów: nie usuwać, nie instalować od nowa, nie „naprawiać szybko” aplikacji. Odłączyć serwer od sieci lub go odizolować, zabezpieczyć logi i obraz systemu oraz rozpocząć uporządkowaną obsługę incydentu.
Czego nie należy robić
- Tylko załatać i pracować dalej. Poprawka nie usuwa wprowadzonego już złośliwego oprogramowania.
- Od razu usuwać podejrzane pliki. Znikają wtedy dowody tego, co się stało i jakie dane mogły zostać dotknięte.
- Stawiać serwer od nowa, zanim zabezpieczono ślady. Przyczyna pozostaje niejasna, a tylna furtka w bazie danych lub dane dostępowe przetrwają ponowną instalację.
- Przywracać stare kopie zapasowe bez sprawdzenia. Także kopia zapasowa może już zawierać tylną furtkę.
- Zapominać o danych dostępowych. Po wykonaniu kodu hasła do baz danych, klucze API i inne dane dostępowe z plików konfiguracyjnych mogły wyciec. Proszę je odnowić po oczyszczeniu, a nie wcześniej, aby wciąż aktywny atakujący nie odczytał od razu nowych.
Gdy podejrzenie się potwierdzi
Wtedy chodzi o więcej niż technikę. Proszę sprawdzić z inspektorem ochrony danych, czy konieczne jest zgłoszenie na podstawie RODO; termin wynosi 72 godziny od uzyskania wiedzy, szczegóły na stronie Obowiązek zgłoszenia na podstawie RODO. Proszę wcześnie poinformować ubezpieczyciela cyber, jeśli istnieje, i wyjaśnić z prawnikiem, czy złożyć zawiadomienie. Udzielamy w tej sprawie ogólnych wskazówek, a nie porad prawnych.
Jak konkretnie pomaga PHP SOS?
Dzięki naszemu Incident Response uporządkowanie opracowujemy podejrzenie:
- Zabezpieczenie: logi od 20 października i, gdzie potrzeba, obraz systemu, zanim cokolwiek zostanie zmienione.
- Badanie: analiza zachowania plików, procesów, połączeń i kont; w razie potrzeby w sposób nadający się do sądu dzięki informatyce śledczej.
- Oczyszczenie i zamknięcie: usunięcie tylnych furtek, aktualizacja PHP, odnowienie danych dostępowych, utwardzenie serwera.
- Dokumentacja, aż incydent zostanie zamknięty i udokumentowany, jako podstawa dla ochrony danych, ubezpieczenia i zarządu.
Częste pytania
Czy aktualizacja PHP dowodzi, że mój serwer jest czysty?
Nie. Poprawka zamyka lukę na przyszłość, ale nie usuwa wprowadzonego już złośliwego oprogramowania. Nie mówi też nic o tym, czy przed poprawką ktoś się włamał.
Czy istnieje skaner, który pewnie rozpoznaje ataki PHP2Shell?
Dotąd nie. Nie ma opublikowanych, potwierdzonych wskaźników naruszenia, których skaner mógłby celowo szukać. Skanery malware znajdują znane webshelle, ale ocena serwera opiera się na analizie zachowania.
Czy muszę zgłosić podejrzenie organowi ochrony danych?
Zależy to od tego, czy mogą być dotknięte dane osobowe. RODO przewiduje dla naruszeń podlegających zgłoszeniu termin 72 godzin od uzyskania wiedzy. Proszę wyjaśnić to wcześnie z inspektorem ochrony danych lub prawnikiem; nie udzielamy w tej sprawie porad prawnych.
Czy mam po prostu postawić zhakowany serwer od nowa?
Nie jako pierwszy krok. Najpierw proszę zabezpieczyć logi i, jeśli to możliwe, obraz systemu. Kto od razu instaluje od nowa, traci ślady, które pokazują, co się stało i jakie dane mogły zostać dotknięte.