Jak wykryć i usunąć złośliwe pliki na stronie

Atak na witrynę rzadko zaczyna się spektakularnie. Częściej to ciche podmiany plików, dodane ukryte konta i niewielkie opóźnienia ładowania. Zanim problem przerodzi się w wyciek danych lub blokadę przez wyszukiwarki, warto wiedzieć, jak szybko wykryć i usunąć złośliwe pliki oraz przywrócić bezpieczne działanie serwisu. Poniższy poradnik prowadzi krok po kroku: od sygnałów ostrzegawczych, przez metody detekcji, po bezpieczne czyszczenie i wzmocnienie zabezpieczeń na przyszłość.

Sygnały infekcji i przygotowanie do działań

Wczesne objawy, które warto traktować poważnie

Nie każdy błąd 500 oznacza włamanie, ale kombinacja objawów powinna wzbudzić czujność. Zwróć uwagę na:

• nagłe przekierowania użytkowników na obce domeny, w tym tylko na urządzeniach mobilnych,
• ostrzeżenia przeglądarek o złośliwym oprogramowaniu lub blokadę przez systemy reklamowe,
• podejrzane wpisy w konsoli przeglądarki, ukryte iframy, wstrzyknięte skrypty,
• przyrost liczby plików w katalogach uploadów i cache bez Twojej ingerencji,
• nietypową aktywność w statystykach serwera (nagły wzrost zapytań POST, ładunki o dziwnych rozszerzeniach),
• nowe konta administracyjne lub modyfikacje ról użytkowników.

W tym momencie działaj jak podczas incydentu bezpieczeństwa: dokumentuj, nie nadpisuj śladów i ogranicz dostęp.

Stabilizacja: kopia, tryb serwisowy, minimalizacja ryzyka

• Krok 1: Utwórz natychmiastową kopię całego środowiska: plików i bazy danych. Najlepiej „zimną” kopię poza serwerem produkcyjnym. Zabezpiecza to dowody i umożliwia późniejsze porównania.
• Krok 2: Włącz tryb serwisowy lub tymczasowo wstrzymaj ruch na poziomie reverse proxy/CDN. Ograniczysz dalsze szkody i rozprzestrzenianie.
• Krok 3: Zresetuj hasła do panelu administracyjnego, SFTP/SSH, bazy danych, oraz tokeny API. Zastąp klucze dostępowe. Nie rób tego tylko po usunięciu plików — zrób to od razu, aby przeciąć aktywne sesje.

Narzędzia i kompetencje: co przygotować zanim zaczniesz

• Możliwość dostępu po SFTP/SSH i wglądu w logi HTTP, PHP-FPM, systemowe.
• Prosty edytor do bezpiecznego przeglądu treści plików i porównywania (diff).
• Skanery plików i bazy znanych wskaźników kompromitacji (IoC). Przyda się wiedza, jak działa skanowanie oparte o sygnatury, oraz analiza heurystyczna.
• Lista referencyjna poprawnych plików i sum kontrolnych (repozytorium Git, paczki instalacyjne CMS-a, oficjalne wtyczki/motywy).

Diagnostyka i wykrywanie złośliwych plików

Automatyczne skanery i ich rola

Narzędzia antywirusowe i dedykowane skanery webowe przyspieszają detekcję. Wykorzystaj je do przesiewu całej przestrzeni hostingowej, w tym katalogów tymczasowych i uploadów. Pamiętaj, że żadna maszyna nie daje 100% pewności — celuj w kombinację metod.

• Uruchom skan z pełnym drzewem katalogów, obejmującym public_html, storage, temp, cache oraz katalogi kopii roboczych.
• Korzystaj z baz IoC dostawców bezpieczeństwa i prostych reguł wykrywania typowych ładunków (np. obecność funkcji eval, exec, gzinflate, base64_decode obok nietypowych ciągów).
• Oceń wyniki: klasyfikuj znaleziska na wysokie ryzyko (np. webshell, dropper), średnie (podejrzane includy), niskie (złośliwe komentarze w JS).

Automaty dość skutecznie wyłapują znane warianty malware, ale mogą ominąć świeże lub zaciemnione implanty. Dlatego łącz automatyczne podejście z przeglądem ręcznym i porównaniami.

Ręczny audyt drzewa plików

• Posortuj pliki po dacie modyfikacji. Niespodziewane zmiany w rdzeniu CMS-a, w katalogach vendor lub systemowych rarely zmieniają się bez aktualizacji — to czerwone flagi.
• Przeglądaj katalogi, które często nadużywają atakujący: uploads, cache, backup, tmp, oraz katalogi z możliwością wykonywania PHP/CGI.
• Szukaj plików o mylących rozszerzeniach (np. obraz.jpg.php), losowych nazwach (a87sd.php) lub ukrytych (kropka na początku nazwy).
• Zwróć uwagę na nietypowe rozmiary: bardzo małe pliki loaderów lub ogromne, spakowane blob’y JS.

Analizując zawartość, wypatruj charakterystycznych wzorców: zaciemnienie przez długie ciągi Base64, łańcuchy funkcji systemowych, wstrzykiwane iframy, dynamiczne includy plików z katalogów do zapisu. Pliki będące backdoor często przyjmują parametry GET/POST do wykonania komend lub przesyłania kolejnych komponentów.

Porównanie z referencją i sumy kontrolne

• Jeśli korzystasz z CMS-a, porównaj pliki rdzenia, motywów i wtyczek z wersjami z repozytoriów. Sprawdź sumy kontrolne, aby potwierdzić integralność — różnice to sygnał do głębszej analizy.
• W projektach z repozytorium Git: wylistuj nieśledzone pliki i modyfikacje. Pamiętaj, że atakujący często umieszczają implanty poza ścieżkami kontrolowanymi przez Git, a także podmieniają pliki środowiskowe.
• Po stronie zależności (Composer/NPM): przeinstaluj od zera, aby wykluczyć zainfekowane paczki vendor.

Analiza dzienników i telemetrii

Przejrzyj serwerowe logi access i error. Szukaj wzorców: liczne próby uploadu, wywołania podejrzanych endpointów, błędy 404 dla plików znanych webshelli, długotrwałe żądania POST. Sprawdź logi uwierzytelnienia, aby wykryć brute-force lub logowania z nietypowych lokalizacji. W telemetrycznych narzędziach APM wypatruj nagłych skoków czasu CPU, I/O, alokacji pamięci.

• Skoreluj moment pojawienia się pierwszego podejrzanego pliku z ruchem w logach — to wskaże vektor wejścia.
• Jeśli masz WAF/CDN, przejrzyj ich zdarzenia blokad i alertów, aby rozpoznać reguły, które nie zadziałały bądź trzeba je wyostrzyć.

Wskaźniki kompromitacji i klasyfikacja

• Łańcuch dostawy: czy pliki pojawiły się po aktualizacji wtyczki, wdrożeniu nowej funkcji, zmianie hostingu?
• Typ ataku: webshell, skrypt do wysyłki spamu, koparka kryptowalut, skimmer kart płatniczych, defacement.
• Trwałość: crony, szkodliwe autoloady, taski w schedulerach, modyfikacje .user.ini lub php.ini.
• Powiązane artefakty: ukryte konta adminów, zmiany w bazie danych (wstrzyknięte fragmenty JS w treściach), nowe wpisy w tabelach ustawień.

Usuwanie złośliwych plików i bezpieczne przywracanie

Izolacja i praca na kopii

Zanim cokolwiek skasujesz, przygotuj kontrolowane środowisko. Przenieś podejrzane pliki do izolowanego miejsca, nadaj im rozszerzenie .quarantine i pozbaw prawa wykonywania. Taka kwarantanna pozwoli na późniejszą analizę bez ryzyka ponownego uruchomienia ładunku.

• Wstrzymaj crony i zadania harmonogramu, aby zatrzymać mechanizmy utrwalające infekcję.
• Wyłącz wykonywanie w katalogach uploadów (Options -ExecCGI, php_flag engine off, deny all dla .php), jeżeli konfiguracja na to pozwala.

Bezpieczne czyszczenie plików i katalogów

• Usuń wszystkie pliki, które nie pochodzą z Twojej bazy referencyjnej i nie są konieczne (szczególnie samodzielne .php w uploadach).
• Przeinstaluj rdzeń aplikacji i oficjalne rozszerzenia z czystych źródeł — nie „naprawiaj” ich ręcznie.
• W katalogach cache i temp wykonaj pełne czyszczenie; wiele implantów kryje się właśnie tam.
• Zwróć uwagę na pliki konfiguracyjne i .htaccess/.user.ini — atakujący często wykorzystują je do utrwalania.

Oczyszczanie bazy danych

Złośliwe wstrzyknięcia rzadko ograniczają się tylko do plików. Przejrzyj treści HTML w bazie, pola z widżetami, ustawieniami i szablonami. Wpisy mogą zawierać skrypty ładujące obce domeny, atrybuty onload/onerror, czy obfuskowany JS. W razie wątpliwości porównaj z kopią sprzed incydentu, a najpewniejszą metodą jest przywrócenie całej bazy do momentu sprzed infekcji i re-aplikacja zmian biznesowych.

Przywracanie i weryfikacja po czyszczeniu

• Odtwórz pliki aplikacji z czystego źródła, a treści użytkownika (media) przefiltruj: pozostaw tylko typy dozwolone, sprawdź nagłówki MIME, usuń pliki wykonywalne.
• Porównaj sumy kontrolne z referencją i ponownie sprawdź integralność instalacji.
• Uruchom testy funkcjonalne: logowanie, dodawanie treści, płatności (jeśli dotyczy), wysyłkę maili. Potwierdź, że nie ma nieautoryzowanych połączeń wychodzących.

Rotacja sekretów i zamknięcie wektorów

• Zmień wszystkie hasła i klucze: panel admina, baza, SFTP/SSH, klucze JWT, secret keys, webhooki. Zresetuj sesje użytkowników i unieważnij tokeny.
• Jeśli były wykorzystywane ujawnione klucze do zewnętrznych usług, odwołaj je w konsolach dostawców.
• Zaktualizuj konfiguracje zgodnie z zasadą minimalizacji — restrykcyjne uprawnienia plików i katalogów ograniczą skutki ewentualnego kolejnego błędu.

Wzmocnienie zabezpieczeń i prewencja na przyszłość

Aktualizacje, zależności i higiena wytwarzania

• Utrzymuj aktualne rdzeń aplikacji, wtyczki, motywy i biblioteki. Włącz automatyczne łatki bezpieczeństwa tam, gdzie to uzasadnione.
• Weryfikuj źródła wtyczek i motywów; unikaj paczek z nieoficjalnych repozytoriów.
• Stosuj CI/CD z kontrolą zmian i skanami składu oprogramowania (SBOM). Każdy deploy powinien odtwarzać pliki z czystych artefaktów.

Kontrola dostępu i twarde ustawienia serwera

• Wymuś MFA, używaj menedżerów haseł, nadawaj najmniejsze konieczne uprawnienia. Ogranicz wykonywanie PHP tylko do katalogów, które tego wymagają.
• Rozdziel konta usług: panel CMS, SSH/SFTP, baza danych. Każde konto tylko do jednej roli.
• Włącz i dopasuj ModSecurity lub dedykowany WAF, aby filtrować podejrzane żądania i uploady. Uzupełnij o reguły dla znanych wektorów RCE/LFI/XSS.
• Zabroń wykonywania binarek systemowych z aplikacji (disable_functions, open_basedir, noexec dla mount), jeśli architektura na to pozwala.

Monitoring, alerty i obserwowalność

• Wdróż monitoring spójności plików (FIM), który alarmuje o nieautoryzowanych zmianach w czasie rzeczywistym.
• Ustaw alerty na nietypowe wzorce w ruchu: nagłe skoki 4xx/5xx, zapytania POST z rzadkich krajów, wielkość odpowiedzi wskazująca na wycieki.
• Agreguj logi w scentralizowanym systemie i ustaw reguły korelacyjne (np. wykrycie wielokrotnych prób uploadu zakończonych błędem, a potem nagłe 200 OK).

Bezpieczne uploady i walidacja danych

• Waliduj rozszerzenia i nagłówki MIME. Przechowuj pliki użytkownika poza katalogiem wykonywalnym, serwuj je przez serwer statyczny lub proxy z wymuszeniem pobierania.
• Skaluj obrazy po stronie serwera, aby pozbyć się zagnieżdżonych ładunków EXIF/ICC. Odrzucaj zbyt duże pliki i nietypowe formaty.
• Stosuj listy dozwolonych wejść zamiast list blokowanych. Sanituzuj HTML/JS w treściach użytkownika.

Kopie zapasowe i odtwarzanie

• Stosuj strategię 3-2-1: trzy kopie, na dwóch różnych nośnikach, co najmniej jedna offline. Regularnie testuj odtwarzanie.
• Wersjonuj kopie i przechowuj metadane, by cofnąć się do chwili sprzed infekcji.
• Automatyzuj tworzenie kopii po istotnych zmianach i przed aktualizacjami.

Przypadki szczególne i praktyczne scenariusze

Popularne CMS-y: WordPress, Joomla, Drupal

• WordPress: zweryfikuj core i wtyczki z repozytorium, usuń porzucone motywy/wtyczki, sprawdź mu-plugins i wp-content/uploads pod kątem wykonywalnych plików. Sprawdź crony i harmonogramy. Usuń edytor plików w panelu, ogranicz xmlrpc, ustaw salting kluczy.
• Joomla/Drupal: zderz pliki z oficjalnymi paczkami, oczyść katalogi sites/default/files lub images, upewnij się, że pliki .php nie są akceptowane w uploadach.

Sklepy internetowe i skimmery płatnicze

W e-commerce priorytetem jest ochrona danych kart. Atakujący doklejają skrypty kradnące dane płatnicze do checkoutu. Szukaj wstrzyknięć w plikach JS i szablonach, obserwuj żądania do zewnętrznych domen podczas finalizacji zamówienia. Po incydencie rozważ audyt PCI i rotację kluczy bramek płatniczych.

SaaS, statyczne strony i zasoby w chmurze

W statycznych witrynach oparcie o CDN i nie wykonywalne hostowanie ogranicza ryzyko, ale nie eliminuje go. Zadbaj o polityki bucketów, podpisywanie URL-i, skan plików uploadowanych przez użytkowników i reguły Content Security Policy. Blokuj inline-scripts i nieznane źródła, aby utrudnić wstrzyknięcia.

Środowiska współdzielone vs. dedykowane

Na hostingu współdzielonym jeden zainfekowany tenant może zwiększać ryzyko dla pozostałych. Ogranicz się do niezbędnego minimalnego zestawu usług, nie trzymaj narzędzi administracyjnych w przestrzeni publicznej, a paneli testowych nie wystawiaj do internetu. W środowiskach własnych wykorzystaj izolację na poziomie kontenerów lub jaili i twarde polityki sieciowe.

Zarządzanie incydentem i obowiązki prawne

Jeżeli istnieje ryzyko naruszenia danych osobowych, rozważ obowiązki notyfikacyjne wynikające z RODO i wymagań branżowych. Zachowaj artefakty do analizy: pamięć, zrzuty logów, kopie plików w stanie sprzed czyszczenia. Zdefiniuj proces post mortem i plan ulepszeń, aby podobny wektor nie zadziałał ponownie.

Na koniec wdrożona warstwa ochrony powinna być wieloskładnikowa: od twardych konfiguracji serwera, przez polityki dostępu, po analizę zachowania i filtrowanie aplikacyjne przez WAF. Pamiętaj, że najlepsze rezultaty da łączenie metod: skanowanie oparte o sygnatury, kontrola integralność plików, analiza logi, izolacja przez kwarantanna, minimalne uprawnienia oraz blokowanie wektorów przez WAF, a kluczowe elementy ryzyka — takie jak malware, backdoor i webshell — będą wykrywane i neutralizowane zanim spowodują szkody.