Krótko: Informatyka śledcza dla serwerów odpowiada na pytanie, co naprawdę wydarzyło się podczas ataku: kiedy, jak i z jakimi skutkami. Wspólnie z wyspecjalizowanymi partnerami zabezpieczamy ślady w sposób dowodowy, analizujemy logi, systemy plików i bazy danych oraz dostarczamy możliwy do prześledzenia raport. Służy on jako podstawa zgłoszeń, ubezpieczenia i w razie potrzeby ścigania.
Kiedy potrzebują Państwo informatyki śledczej dla swojego serwera
Nie każdy incydent wymaga dochodzenia śledczego. Jest ono sensowne przede wszystkim wtedy, gdy mogły zostać naruszone dane osobowe, dane płatnicze lub tajemnice przedsiębiorstwa, gdy przewidywane jest zawiadomienie lub spór prawny albo gdy ubezpieczyciel oczekuje wiarygodnego dowodu. Także przy pytaniu, czy konieczne jest zgłoszenie do organu nadzorczego, udokumentowane fakty pomagają bardziej niż przypuszczenia.
Po PHP2Shell dochodzi szczególny punkt. Luki CVE-2026-109618 i CVE-2026-109619 umożliwiają wykonanie kodu bez logowania i nie ma opublikowanych, potwierdzonych wskaźników naruszenia (Indicators of Compromise). Czy serwer był dotknięty, nie da się więc „odhaczyć” na liście kontrolnej, lecz tylko ustalić analizą zachowania: jakie procesy działały, jakie pliki powstały, jakie połączenia wychodziły? Pierwsze wskazówki daje strona Czy już doszło do naruszenia?.
Czym informatyka śledcza różni się od szybkiego oczyszczenia
Oczyszczanie chce znów uczynić serwer czystym. Informatyka śledcza chce zrozumieć i udowodnić. Jedno pytanie brzmi: „Czy serwer jest znów bezpieczny?”, drugie: „Co dokładnie się stało i jakie dane były osiągalne?”. Dla zgłoszeń, ubezpieczenia i informowania klientów rozstrzygające jest zwykle drugie pytanie. Oba da się pogodzić, jeśli kolejność jest właściwa: najpierw zabezpieczyć, potem zmieniać. Kto najpierw usuwa, łata lub restartuje, traci ulotne ślady i często później nie może już wykazać, co atakujący zobaczył.
Proszę zachować wszystkie logi serwera od 20.10.2026 i poprosić dostawcę hostingu, aby nie rotował ani nie usuwał dzienników. Brakujące logi są najczęstszą przyczyną otwartych pytań w raporcie.
Które ślady na serwerze WWW z PHP mają znaczenie
Na typowym serwerze WWW jest więcej śladów, niż wielu operatorów przypuszcza. To, czy nadają się do wykorzystania, zależy od tego, jak długo są przechowywane i czy zostały zabezpieczone przed ingerencją.
- Dzienniki dostępu i błędów serwera WWW oraz PHP-FPM, łącznie z awariami workerów
- System plików: nowe lub zmienione pliki, ich znaczniki czasu i właściciele, wykonywalny kod w folderach uploadów
- Baza danych: nowe konta użytkowników, zmienione ustawienia, wprowadzone treści
- System: zadania cron, użytkownicy, klucze SSH, dzienniki logowań, działające procesy i połączenia sieciowe
- Systemy poprzedzające: dzienniki CDN, WAF, firewalla, load balancera i serwera pocztowego
Właśnie systemy poprzedzające bywają zapominane. Leżą poza serwerem WWW, więc atakującemu trudniej je zmanipulować. U niektórych dostawców przechowywane są tylko krótko, dlatego należy je wyeksportować wcześnie.
Jak konkretnie pomaga PHP SOS?
- Wyjaśnienie zlecenia: Ustalamy z Państwem, na jakie pytania ma zostać udzielona odpowiedź, na przykład droga włamania, okres, dotknięte dane lub przemieszczanie się w sieci. Z tego wynika, które systemy zostaną zbadane.
- Zabezpieczenie dowodowe: My i nasi wyspecjalizowani partnerzy tworzymy kopie nośników danych, logów, baz danych i, jeśli to możliwe, pamięci operacyjnej. Każda kopia otrzymuje sumę kontrolną, a każde przekazanie jest dokumentowane.
- Analiza: Analizujemy dzienniki dostępu i błędów, zmiany plików, konta użytkowników, zadania cron, procesy i połączenia wychodzące. Metodykę dla logów opisuje strona Analiza logów serwera WWW po ataku.
- Sporządzenie osi czasu: Ze znalezisk powstaje oś czasu incydentu, w której każde stwierdzenie odsyła do konkretnego dowodu.
- Przekazanie raportu: Otrzymują Państwo raport techniczny i zrozumiałe podsumowanie dla zarządu.
Co Państwo otrzymują i czego potrzebujemy
Raport zawiera zabezpieczone dowody z sumami kontrolnymi, dokumentację łańcucha przekazania, oś czasu, ustaloną lub prawdopodobną drogę włamania, dotknięte systemy i rodzaje danych oraz zalecenia. Każde stwierdzenie jest oznaczone jako udowodnione, prawdopodobne lub nieznane.
Od Państwa potrzebujemy:
- dostępu do dotkniętych systemów lub zgody, aby Państwa dostawca hostingu udostępnił nam kopie
- osoby uprawnionej do decyzji, która określi zakres i priorytety
- informacji o środowisku systemowym, usługodawcach i znanych zmianach z ostatnich tygodni
- istniejących dzienników, także z firewalli, CDN, WAF lub serwerów pocztowych
- informacji, czy ubezpieczyciel, policja lub prawnik są już zaangażowani
Jeśli chcą Państwo złożyć zawiadomienie, wskazówki znajdą Państwo na stronie Składanie zawiadomienia: centralne punkty kontaktowe ds. cyberprzestępczości. Czego ubezpieczyciele zwykle oczekują w razie szkody, wyjaśnia strona Ubezpieczenie cyber: co się liczy w razie szkody.
Czego nie obiecujemy
Informatyka śledcza może analizować tylko te ślady, które istnieją. Jeśli logi brakują, zostały nadpisane lub zmanipulowane przez atakującego, pozostają luki, które wskazujemy. Nie obiecujemy, że sąd oceni nasze wyniki w określony sposób, i nie dokonujemy oceny prawnej. Nie wskazujemy sprawców, lecz opisujemy, co pokazują ślady. Stwierdzeń takich jak „na pewno żadne dane nie wyciekły” dokonujemy tylko wtedy, gdy popierają je dowody.
Jeśli atak wciąż trwa, pierwszeństwo ma powstrzymanie. Zaczynamy wtedy od Incident Response i równolegle zabezpieczamy jak najwięcej śladów.
Częste pytania
Co oznacza zabezpieczenie dowodów nadające się do sądu?
Ślady są zabezpieczane tak, aby później dało się wykazać, że pozostały niezmienione. Należą do tego sumy kontrolne, udokumentowany łańcuch przekazania i praca na kopiach zamiast na oryginale. Czy sąd wykorzysta dany dowód, rozstrzyga jednak sąd.
Czy informatyka śledcza może wyjaśnić, czy dane klientów wyciekły?
Często można zawęzić, do jakich danych atakujący miał dostęp i czy istnieją wskazówki wycieku. Pewne wykluczenie nie zawsze jest możliwe, zwłaszcza gdy brakuje logów. Dlatego wynik jest podzielony na udowodniony, prawdopodobny i nieznany.
Jak długo należy przechowywać logi?
Dla wyjaśnienia sprawy jak najdłużej, co najmniej do zakończenia dochodzenia. Przy PHP2Shell prasa branżowa radzi zachować logi serwera od 20.10.2026. Prawne obowiązki przechowywania i usuwania proszę wyjaśnić z inspektorem ochrony danych.
Czy mogę zrestartować lub załatać serwer przed analizą śledczą?
Restart usuwa ulotne ślady w pamięci operacyjnej, poprawka zmienia pliki. Jeśli to możliwe, proszę najpierw wykonać kopię zabezpieczającą lub krótko z nami porozmawiać. Jeśli zagrożenie jest ostre, pierwszeństwo ma powstrzymanie ataku, co jest dokumentowane.