# Czy już doszło do naruszenia? Oznaki po PHP2Shell

> Serwer zhakowany? Typowe oznaki po PHP2Shell, pierwsze kontrole bez utraty śladów i co robić przy podejrzeniu, krok po kroku.

Źródło: https://phpsos.de/pl/php2shell/bin-ich-gehackt-anzeichen/  
Stan: 25.10.2026  
Dostawca: PHP SOS, Pomoc awaryjna PHP i bezpieczeństwo serwerów. Natychmiastowa pomoc przez WhatsApp: https://wa.me/491736494914?text=Dzie%C5%84%20dobry%2C%20PHP%20SOS%2C%20potrzebujemy%20pomocy%20z%20naszym%20serwerem%20PHP.%20Firma%3A%20%E2%80%A6%20Strona%20internetowa%3A%20%E2%80%A6

**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:

```bash
# 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](https://phpsos.de/pl/ratgeber/logfiles-auswerten/); jak znajdować tylne furtki, strona [Rozpoznawanie i usuwanie webshelli](https://phpsos.de/pl/ratgeber/webshell-erkennen/).

> **Działać natychmiast:**
> 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](https://phpsos.de/pl/compliance/dsgvo-meldepflicht-72-stunden/). 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](https://phpsos.de/pl/leistungen/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](https://phpsos.de/pl/leistungen/it-forensik/).
- **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.

## Źródła

- [php.net: komunikaty o bezpieczeństwie](https://www.php.net/)
- [BSI: Federalny Urząd ds. Bezpieczeństwa Informacji (Niemcy)](https://www.bsi.bund.de/)
- [RODO art. 33: zgłoszenie do organu nadzorczego](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)