Złośliwe pliki na serwerze potrafią długo pozostawać niezauważone, a ich skutki często wychodzą na jaw dopiero wtedy, gdy strona zaczyna rozsyłać spam, przekierowuje użytkowników na podejrzane domeny, pojawiają się nieautoryzowane procesy lub hosting zgłasza nadużycia. W środowisku hostingu współdzielonego, VPS i serwerów dedykowanych ryzyko jest realne, bo atakujący wykorzystują zarówno luki aplikacji (CMS, wtyczki), jak i błędną konfigurację usług czy słabe hasła. Wykrywanie szkodliwych plików to nie pojedyncze narzędzie, lecz zestaw praktyk: analiza zmian w plikach, skanowanie sygnaturowe, heurystyka, kontrola integralności oraz korelacja zdarzeń z logów. Poniżej znajduje się zestaw metod, które pomagają wykryć infekcję wcześnie i ograniczyć jej rozmiar.

Skąd biorą się złośliwe pliki na hostingu i jak wyglądają objawy

Żeby skutecznie wykrywać złośliwe pliki, warto rozumieć typowe wektory ataku. Najczęściej początek stanowi podatność w aplikacji webowej, a dopiero potem pojawia się “dziwny plik” w katalogu strony. Atakujący dążą do uzyskania zapisu w przestrzeni, do której ma dostęp użytkownik WWW, a następnie zostawiają elementy trwałości: webshell, backdoor, zadanie cron albo modyfikację plików wejściowych aplikacji.

W praktyce spotyka się kilka powtarzalnych scenariuszy:

• Nieaktualny CMS lub wtyczka umożliwia upload pliku i wykonanie go przez interpreter (np. PHP).
• Wykradzione dane FTP/SFTP powodują “ciche” podmiany plików w nocy lub w seriach po kilkaset plików.
• Złe uprawnienia i brak izolacji kont w środowisku współdzielonym pozwalają na eskalację do innych katalogów.
• Wstrzyknięcia do bazy danych (np. w treści wpisów) generują dynamicznie złośliwy kod na stronie, ale często zostawiają też pliki pomocnicze w cache lub uploads.

Objawy, które powinny uruchomić procedurę sprawdzenia, to m.in. nagłe skoki użycia CPU, procesy PHP działające długo po zakończeniu ruchu, wysyłka poczty z serwera, alerty od przeglądarki o złośliwej stronie, przekierowania na losowe domeny, a także nieoczekiwane zmiany w plikach rdzenia CMS. Warto zapamiętać, że infekcja nie zawsze jest “widoczna” w kodzie strony głównej — często siedzi w rzadko odwiedzanych skryptach, w katalogach tymczasowych lub w plikach o nazwach udających systemowe.

Na co polują atakujący? Najczęściej na możliwość uruchomienia dowolnych poleceń, kradzież danych, rozsyłanie spamu oraz wykorzystanie serwera jako przystanku do dalszych ataków. Po stronie administratora kluczowe jest szybkie wykrycie artefaktów typu webshell, ukrytych wtyczek, modyfikacji plików index.php, nietypowych plików w uploads oraz podejrzanych zadań cron.

Szybka diagnostyka: gdzie szukać i co sprawdzać w pierwszej kolejności

Jeżeli podejrzewasz infekcję, pierwsze kroki powinny maksymalnie ograniczać ryzyko nadpisania śladów. Zanim zaczniesz “czyścić”, zbierz podstawowe informacje: kiedy zaczęły się problemy, jakie konta i domeny są dotknięte, czy zmieniły się parametry hostingu, czy były wdrożenia. Następnie wykonaj kopię do analizy (snapshot VPS, kopia katalogów, eksport bazy) i dopiero przechodź do działań naprawczych.

Analiza zmian w plikach (czas modyfikacji, przyrosty, anomalie)

Najbardziej praktycznym krokiem jest sprawdzenie, co zmieniło się ostatnio. Zmiany “hurtowe” w krótkim czasie to częsty sygnał podmiany przez skrypt lub automat.

• Porównaj listę plików CMS z czystą paczką tej samej wersji (różnice zwykle widać natychmiast).
• Sprawdź katalogi: uploads, cache, tmp, vendor, oraz nietypowe podkatalogi o losowych nazwach.
• Zwróć uwagę na pliki z podwójnymi rozszerzeniami (np. image.jpg.php) i na “udawane” pliki graficzne o podejrzanie małym rozmiarze.

W środowiskach linuksowych dobrze działa podejście oparte o “nowe lub zmienione pliki” z ostatnich X dni i ich grupowanie. Jeśli pliki rdzenia CMS są zmienione, to zwykle nie przypadek. Jeżeli zmienione są wyłącznie pliki w uploads, sprawdź, czy serwer nie wykonuje PHP w tym katalogu (to częsty błąd).

Grepy i wzorce: szybkie polowanie na charakterystyczne fragmenty

Duża część złośliwego kodu w PHP ma podobne cechy: zaciemnianie, dekodowanie base64, dynamiczne wywołania funkcji, łączenie ciągów znaków, użycie eval lub assert. Dlatego skuteczne jest skanowanie pod kątem fraz i konstrukcji, ale z ostrożnością: fałszywe alarmy też się zdarzają.

• Szukaj: eval, base64_decode, gzinflate, str_rot13, preg_replace z modyfikatorem /e (w starszym kodzie), shell_exec, passthru, system, proc_open.
• Sprawdzaj długie linie kodu (kilka tysięcy znaków), nietypowe “blokowe” komentarze, oraz ciągi podobne do zaszyfrowanych.
• Weryfikuj pliki zaczynające się od niewidocznych znaków lub z wtrąconym kodem przed <?php (np. BOM lub ukryty payload).

Atakujący często dopisują jeden wiersz do legalnego pliku, np. na końcu functions.php lub pliku szablonu. Takie drobne modyfikacje są trudniejsze do zauważenia “na oko”, dlatego warto polegać na kontroli integralności i porównaniu z repozytorium, jeśli projekt jest wersjonowany.

Logi: korelacja zdarzeń i punkt wejścia

Pliki to skutek, logi często pokazują przyczynę. Przegląd logów WWW (access/error), PHP-FPM, SSH oraz paneli hostingowych pozwala znaleźć punkt wejścia: konkretny endpoint wtyczki, nietypowy User-Agent, falę POSTów na xmlrpc.php, próby uploadu lub wywołania pliku w uploads.

• W access logach szukaj anomalii: duża liczba żądań do jednego pliku, nietypowe parametry (np. “cmd=”), wywołania plików, które nie powinny być publiczne.
• W error logach wypatruj ostrzeżeń o include/require do ścieżek z uploads lub /tmp oraz błędów typu “failed to open stream” (mogą wskazywać sondowanie).
• W logach poczty (jeśli serwer wysyła) sprawdź masowe wysyłki i adresy docelowe. Spam to częsty skutek webshella.

Jeżeli nie znajdziesz źródła, sama podmiana plików może dać krótką ulgę, ale infekcja wróci (np. przez pozostawiony cron albo furtkę w innym katalogu). Dlatego diagnostyka powinna zawsze obejmować także harmonogram zadań, procesy i konfigurację.

Narzędzia i techniki wykrywania: od skanerów po kontrolę integralności

Skuteczne wykrywanie złośliwych plików to połączenie automatyki i manualnej weryfikacji. W hostingu współdzielonym część narzędzi może być ograniczona, ale na VPS/dedykach masz pełną swobodę. Najważniejsze jest, by narzędzia uruchamiać cyklicznie i zbierać wyniki w sposób umożliwiający porównania w czasie.

Skanery antywirusowe i sygnaturowe

Skanery sygnaturowe wykrywają znane próbki i rodziny malware. Ich zaletą jest szybkość oraz prostota, wadą: podatność na modyfikacje i zaciemnianie. Mimo to to dobry fundament, zwłaszcza jako pierwszy filtr.

• ClamAV (często dostępny na serwerach linuksowych) – dobry do okresowych skanów i integracji z automatyzacją.
• Rozwiązania komercyjne lub hostingowe skanery plików – często mają lepsze bazy dla popularnych CMS.
• Skanery “CMS-aware” – potrafią porównać pliki rdzenia i wykryć obce pliki w katalogach aplikacji.

Ważne: ustaw skanowanie tak, by obejmowało nie tylko public_html, ale też katalogi tymczasowe użytkownika, backupy, archiwa ZIP oraz miejsca, gdzie aplikacja może zapisywać pliki (uploads, cache). Złośliwy kod bywa przechowywany w archiwum i rozpakowywany dopiero w razie potrzeby.

Heurystyka i reguły (YARA, własne detektory)

Jeżeli zarządzasz wieloma serwerami, rozważ podejście oparte o reguły. YARA pozwala opisać cechy plików (ciągi, struktury, warunki) i wykrywać podobieństwa do znanych kampanii. To przydatne, gdy atakujący modyfikuje sygnatury, ale zachowuje pewne stałe elementy.

• Reguły na obecność charakterystycznych ciągów: “eval(base64_decode(” + warunek na długość.
• Wykrywanie “dropperów” – małych plików, które pobierają payload z zewnątrz.
• Reguły na webshellowe interfejsy (parametry “cmd”, “exec”, “upload”, “pass”).

Heurystyka nie zastąpi analizy, ale świetnie skaluje się przy wielu kontach hostingowych. Warto utrzymywać repozytorium reguł i wersjonować je jak kod.

Kontrola integralności plików i baseline

Najpewniejszą metodą wykrycia podmiany jest porównanie z “bazą prawdy”. W projektach trzymanych w git sprawa jest prosta: każda różnica jest widoczna. W typowym hostingu, gdzie pliki są wgrywane przez FTP, warto zbudować baseline: sumy kontrolne i listę dozwolonych plików.

• Twórz snapshot kontrolny po wdrożeniu i aktualizacji (hashy plików, listy uprawnień i właścicieli).
• Wykrywaj nowe pliki w katalogach, gdzie nie powinny się pojawiać (np. w katalogu rdzenia CMS).
• Monitoruj zmiany uprawnień: pliki nagle stają się wykonywalne albo pojawia się zapis dla “others”.

Integralność jest szczególnie istotna dla plików startowych, autoloaderów, plików konfiguracyjnych i szablonów. Jeśli atakujący zmieni jeden plik wrdzenia, to kontrola integralności wykryje to szybciej niż skaner sygnaturowy.

Monitorowanie behawioralne: procesy, połączenia sieciowe, zapisy do dysku

Złośliwy plik bywa tylko narzędziem do uruchomienia działań w systemie. Dlatego obserwacja zachowania usług często ujawnia problem wcześniej niż przegląd katalogów.

• Nietypowe procesy: długie procesy php-fpm, uruchamianie sh z kontekstu WWW, częste wywołania curl/wget.
• Połączenia wychodzące do nieznanych domen, zwłaszcza na nietypowe porty.
• Wzrost liczby zapisów w katalogach cache/tmp, tworzenie wielu małych plików w krótkim czasie.

Na VPS i dedykach przydatne są narzędzia typu auditd, systemy EDR lub prostsze mechanizmy monitoringu, które wykrywają nagłe odchylenia. W hostingu współdzielonym część tej telemetrii może być po stronie dostawcy, ale nadal możesz analizować logi aplikacji oraz wprowadzić własne metryki.

Najczęstsze miejsca ukrywania złośliwych plików i popularne sztuczki

Atakujący chcą przetrwać aktualizacje i nie rzucać się w oczy. Dlatego chętnie wybierają miejsca, które “naturalnie” zawierają dużo plików albo często się zmieniają. W praktyce warto regularnie kontrolować kilka obszarów.

• Katalog uploads i media – bo jest pełen plików i często ma prawa zapisu dla WWW. Jeśli serwer wykonuje PHP w uploads, ryzyko rośnie radykalnie.
• Katalogi cache i tmp – pliki mogą wyglądać jak cache, mieć losowe nazwy i krótkie czasy życia.
• Kopie zapasowe w publicznym katalogu (backup.zip, old.tar.gz) – zawierają konfiguracje i hasła, a czasem też stary zainfekowany kod.
• Pliki “podobne do systemowych”: wp-cron.php, xmlrpc.php, admin-ajax.php (modyfikacje lub podstawienia).
• Nietypowe pliki .php w katalogach z zasobami statycznymi (css/js/images) lub pliki .phtml, .phar.

Popularną sztuczką jest tworzenie plików z nazwą bardzo podobną do legalnej (np. class.wp.php zamiast class.php) albo dodawanie kodu do plików, które i tak są często modyfikowane (customizer, pliki motywu). Uważaj też na wstrzyknięcia w plikach .htaccess: ukryte przekierowania, warunki na User-Agent, reguły aktywujące się tylko dla Googlebota albo tylko dla ruchu z określonych krajów.

Na serwerach z kilkoma stronami nie ignoruj ryzyka “lateral movement”: infekcja jednej domeny może być wykorzystana do modyfikacji innych, jeśli izolacja kont i uprawnienia są zbyt luźne. Tam, gdzie to możliwe, stosuj separację użytkowników, osobne pule PHP-FPM, oraz ograniczenia open_basedir.

Procedura reagowania: jak potwierdzić infekcję i nie dopuścić do powrotu

Wykrycie złośliwego pliku to dopiero połowa sukcesu. Jeżeli usuniesz tylko widoczny objaw, atakujący często wróci przez ten sam wektor lub przez pozostawioną furtkę. Skuteczna procedura powinna obejmować: potwierdzenie, identyfikację źródła, czyszczenie, zamknięcie podatności i weryfikację po czasie.

Izolacja i zabezpieczenie materiału

• Ogranicz dostęp zewnętrzny, jeśli infekcja aktywnie szkodzi (np. rozsyła spam, generuje przekierowania).
• Zrób kopię plików i bazy do analizy oraz archiwum z logami.
• Jeśli to możliwe, wykonaj snapshot VPS przed zmianami, by móc wrócić do stanu sprzed czyszczenia.

Czyszczenie: usuń artefakty i przywróć czysty kod

Usuń złośliwe pliki, ale przede wszystkim przywróć legalne pliki z zaufanego źródła. W przypadku CMS najbezpieczniej jest podmienić rdzeń na świeżą paczkę tej samej wersji (a następnie zaktualizować), a motyw i wtyczki zainstalować ponownie z oficjalnych repozytoriów. Jeśli wtyczka była pobrana z niesprawdzonego źródła, lepiej ją całkowicie usunąć.

Sprawdź też bazę danych: złośliwe skrypty potrafią zapisać payload w opcjach, widgetach, wpisach lub tabelach konfiguracji. To częsty powód “nawracających” problemów mimo czystych plików.

Zamknięcie wektora: aktualizacje, hasła, konfiguracja

• Wymuś zmianę haseł: panel hostingowy, SSH, SFTP/FTP, baza danych, konta administracyjne CMS. Włącz 2FA tam, gdzie to możliwe.
• Zaktualizuj CMS, wtyczki, motywy oraz interpreter (PHP) i biblioteki.
• Zweryfikuj uprawnienia plików i katalogów, wyłącz wykonywanie PHP w uploads, ogranicz zapisy tam, gdzie nie są potrzebne.
• Przejrzyj cron, systemd timery, zadania w panelu hostingu i wszelkie “automatyk” uruchamiające skrypty.

Weryfikacja i obserwacja po incydencie

Po czyszczeniu uruchom ponownie skanery, sprawdź integralność oraz monitoruj logi przez kilka dni. Infekcje, które wracają, zwykle oznaczają, że albo luka nadal istnieje, albo gdzieś pozostał backdoor. Dobrym testem jest także porównanie listy plików do baseline oraz sprawdzenie, czy nie pojawiają się nowe, podejrzane pliki w katalogach zapisywalnych.

Strategia długoterminowa: jak wykrywać wcześniej i rzadziej gasić pożary

Najtańsza infekcja to ta, która została zatrzymana zanim doszło do masowej podmiany plików. W praktyce na serwerach i hostingach sprawdza się połączenie automatycznych skanów, sensownej polityki uprawnień, regularnych aktualizacji i minimalizacji powierzchni ataku.

• Ustal cykliczne skany plików oraz skany po wdrożeniach i aktualizacjach.
• Wprowadź baseline integralności i alarmy na zmiany w kluczowych plikach.
• Ogranicz możliwość zapisu przez użytkownika WWW tylko do katalogów, które tego wymagają.
• Stosuj WAF lub filtrowanie żądań dla typowych ataków (brute force, skanowanie podatności, podejrzane uploady).
• Trzymaj kopie zapasowe poza serwerem i testuj odtwarzanie. Backup na tym samym hostingu w publicznym katalogu często sam staje się problemem.

W środowiskach z wieloma klientami (reseller, hosting współdzielony) szczególnie ważna jest separacja kont oraz ograniczanie skutków infekcji: osobne użytkowniki systemowe, izolacja procesów, limity zasobów i kontrola wyjściowego SMTP. Nawet jeśli nie unikniesz wszystkich prób ataku, wcześnie wykryta anomalia pozwoli zareagować zanim pojawią się konsekwencje wizerunkowe i techniczne, takie jak blacklisty, spadek SEO czy blokady po stronie operatorów.

W codziennej praktyce najwięcej daje konsekwencja: aktualizacje, porządek w plikach, przegląd logów i automatyzacja skanów. Złośliwe pliki rzadko są “magiczne” — zwykle zostawiają ślady w postaci zmian w systemie plików, podejrzanych wywołań w logach i niepasujących wzorców w kodzie. Jeśli połączysz te źródła informacji, wykrywanie staje się procesem przewidywalnym, a nie loterią.