Strona przekierowuje na reklamy, ale tylko z telefonu — co to jest i jak to usunąć

Typowe zgłoszenie brzmi tak: klient dzwoni, że moja strona otwiera mu jakieś reklamy, a u mnie wszystko jest w porządku. Właściciel sprawdza na komputerze, wszystko działa, więc uznaje, że klient ma wirusa na telefonie. Tymczasem to strona jest zainfekowana, a kod po prostu wie, komu pokazać przekierowanie.

Dlaczego tylko z telefonu

Złośliwy kod przed podjęciem decyzji sprawdza kilka rzeczy:

• identyfikator przeglądarki (User‑Agent): telefon dostaje przekierowanie, komputer nie;
• skąd przyszedł odwiedzający: wejście z Google lub Facebooka dostaje przekierowanie, wpisanie adresu ręcznie nie;
• ciasteczko: przekierowanie jest pokazywane raz na dobę, żeby trudno je było powtórzyć;
• czy użytkownik jest zalogowany do panelu: administrator nigdy nie zobaczy przekierowania.

To celowe. Właściciel strony prawie zawsze wchodzi z komputera, wpisując adres ręcznie, zalogowany. Jest ostatnią osobą, która zobaczy problem. Technika nazywa się cloaking i jest standardem w kampaniach, które zarabiają na odsprzedaży ruchu: do loterii, fałszywych aktualizacji, aplikacji „antywirusowych”, stron dla dorosłych.

Jak to zobaczyć samemu

Udawaj telefon, który przyszedł z Google, bez ciasteczek:

curl -s -L -A "Mozilla/5.0 (Linux; Android 14) AppleWebKit/537.36 Chrome/124 Mobile Safari/537.36" \
  -e "https://www.google.com/" https://twojadomena.pl -o /dev/null -w "%{url_effective}\n"

Jeśli ostatni adres jest inny niż Twoja domena, przekierowanie działa po stronie serwera. Jeśli adres się zgadza, przekierowanie może być w JavaScripcie. Wtedy pobierz HTML i poszukaj:

curl -s -A "Mozilla/5.0 (Linux; Android 14) Mobile" https://twojadomena.pl | grep -io "location\.\(href\|replace\)[^;]\{0,120\}\|<script src=\"http[^\"]*\"" | head

Zewnętrzne skrypty z domen, których nie znasz, i wywołania location.href w zaciemnionym kodzie to to, czego szukasz. Alternatywnie: otwórz stronę w trybie prywatnym na telefonie, z wyników Google. Tryb prywatny usuwa ciasteczka, więc zobaczysz to, co klient.

Gdzie siedzi kod

Przekierowanie może być w jednym z czterech miejsc, a często w kilku naraz.

1. Pliki PHP

W WordPressie najczęściej wp-content/themes/motyw/functions.php, header.php, nieznana wtyczka w wp-content/plugins/ albo wp-content/mu-plugins/ (ten katalog nie pokazuje się w panelu jako normalne wtyczki). W Joomli templates/nazwa/index.php, wtyczki systemowe w plugins/system/ i pliki rdzenia w libraries/. Kod sprawdza User‑Agent i wysyła nagłówek Location.

2. Baza danych

Skrypt wstrzyknięty do treści. W WordPressie do wp_options (klucz siteurl, home, ustawienia widżetów), wp_posts (do każdego wpisu doklejony <script>). W Joomli do tabeli _extensions (parametry), _modules (moduł Custom HTML), _content. Skanery plików tego nie znajdują, bo to nie pliki.

3. .htaccess

Reguły RewriteCond %{HTTP_USER_AGENT} dla telefonów i RewriteRule na obcy adres. Działa bez PHP, więc przeżywa nawet reinstalację CMS‑a.

4. Zewnętrzny skrypt doklejony do szablonu

Jedna linia <script src="https://obca-domena/stat.js"> w nagłówku. Skrypt zmienia się po stronie atakującego, więc dziś pokazuje reklamę, jutro coś innego.

Jak to usunąć, żeby nie wróciło

1. Kopia plików i bazy. Zawsze.
2. Pliki: porównaj rdzeń i motyw z oficjalnym wydaniem, przywróć oryginały. Nieznane wtyczki i pliki w mu-plugins, uploads, images, tmp do kwarantanny.
3. Baza: przeszukaj pod kątem <script, eval(, base64 i obcych domen w tabelach z opcjami i treścią. Usuń doklejone fragmenty, nie całe rekordy.
4. .htaccess: przywróć domyślny dla swojego CMS‑a.
5. Hasła i sole: zmień wszystkie, unieważnij sesje. Inaczej atakujący wejdzie jeszcze raz tą samą drogą.
6. Aktualizacja CMS‑a i rozszerzeń. Przekierowania mobilne w ostatnich latach wchodzą głównie przez luki we wtyczkach.
7. Sprawdź jeszcze raz komendą z początku wpisu, z telefonu w trybie prywatnym i w Google Search Console (sekcja Bezpieczeństwo).

Jeśli po usunięciu plików przekierowanie wciąż jest, szukaj w bazie danych. O tym jest osobny wpis.