Infekcja zniszczyła plik, a kopii nie ma — jak odzyskać go z archiwum internetu

Najgorsza wiadomość przy naprawie brzmi tak: plik był zainfekowany w całości, nie da się go oczyścić, a kopii zapasowej nie ma. Dotyczy to zwykle plików szablonu, które injector nadpisał własną treścią, albo skryptów JS i arkuszy CSS, do których doklejono kod, a potem ktoś je „wyczyścił” do zera. Dla plików rdzenia CMS‑a mamy oficjalne wydanie. Dla plików Twojego szablonu nie ma skąd wziąć oryginału. Chyba że z archiwum internetu.

Co przechowuje archiwum

Wayback Machine (web.archive.org) regularnie odwiedza publiczne strony i zapisuje to, co widzi: HTML każdej podstrony oraz pliki, do których ten HTML się odwołuje, czyli CSS, JavaScript, obrazki, czcionki. Dla popularniejszych stron ma dziesiątki zapisów rocznie, dla małych kilka. Każdy zapis ma datę, więc da się wybrać wersję sprzed infekcji.

Kluczowe ograniczenie: archiwum widzi stronę jak przeglądarka. Dostaje wynik działania PHP, nie sam kod PHP. Dlatego:

Wygenerowany HTML jest cenniejszy, niż się wydaje. Gdy plik index.php szablonu jest nie do odzyskania, zarchiwizowany HTML strony pokazuje, jaką strukturę ten szablon generował: które klasy, jaka kolejność sekcji, jakie pozycje modułów. Z tego da się odbudować szablon ręcznie.

Jak znaleźć właściwą wersję

1. Wejdź na https://web.archive.org/web/*/twojadomena.pl/*. Zobaczysz listę wszystkich zapisanych adresów w domenie z filtrem po typie i dacie.
2. Ustal datę infekcji. Najpewniej z daty modyfikacji zainfekowanego pliku (ls -l --time-style=full-iso) albo z logów. Wybieraj zapisy co najmniej kilka dni wcześniejsze, bo infekcja mogła być aktywna, zanim ją zauważono.
3. Pobierz plik z konkretnej daty. Adres ma postać:

https://web.archive.org/web/20260315000000id_/https://twojadomena.pl/templates/firma/css/template.css

Przyrostek id_ po dacie jest ważny: bez niego archiwum dokleja do pliku własny pasek nawigacyjny i przepisuje adresy. Z id_ dostajesz oryginalną treść bajt w bajt. Datę w adresie wystarczy podać w przybliżeniu; archiwum przekieruje do najbliższego zapisu.

Z linii poleceń:

curl -sL "https://web.archive.org/web/20260315id_/https://twojadomena.pl/templates/firma/css/template.css" -o template.css

Jak sprawdzić, że to czysta wersja

Zanim wgrasz plik z archiwum na serwer, obejrzyj go. W CSS i JS szukaj tego samego, czego szukałbyś na serwerze: eval(, atob(, fromCharCode, document.write, adresów obcych domen, długich ciągów w base64. Zapis sprzed infekcji nie powinien zawierać żadnego z nich. Jeśli zawiera, infekcja jest starsza, niż myślisz; cofnij się do wcześniejszej daty.

Porównaj też rozmiar z wersją na serwerze. Zainfekowany plik jest zwykle większy (doklejony kod) albo drastycznie mniejszy (nadpisany).

Czego archiwum nie zrobi za Ciebie

• Nie odzyska pliku, którego nikt nie odwiedził. CSS ładowany tylko na podstronie, do której archiwum nie dotarło, nie został zapisany.
• Nie odzyska strony, która blokowała roboty. robots.txt z regułą blokującą archiwum albo strona za hasłem to brak zapisów.
• Nie odzyska plików z ostatnich dni. Zapisy pojawiają się z opóźnieniem.
• Nie zastąpi kopii zapasowej. To ostatnia deska ratunku, nie strategia.

Jak robimy to w CleanOps

Gdy skan uzna plik statyczny (CSS, JS, obrazek) za zniszczony lub w całości złośliwy, a strona go potrzebuje, panel próbuje odzyskać wersję z archiwum sprzed daty infekcji. Odzyskany plik jest sprawdzany tymi samymi regułami co pliki z serwera; zainfekowana wersja trafia do kwarantanny, a nie do kosza, więc porównanie zawsze jest możliwe. Dla plików PHP tej drogi nie ma, z jednym wyjątkiem: zniszczony index.php szablonu Joomli panel potrafi odtworzyć na podstawie zarchiwizowanego HTML strony głównej, bo struktura szablonu jest w nim widoczna. W pozostałych przypadkach panel mówi to wprost i zostaje odtworzenie ręczne albo pomoc devopsa.

Po odzyskaniu

Zrób kopię zapasową. Teraz, nie „kiedyś”. Następnym razem archiwum może nie mieć właściwej wersji.