Перенаправлення відвідувачів на рекламу, казино, фішингові сторінки або сумнівні мобільні застосунки часто свідчить про зараження сайту шкідливим кодом. Власник може бачити звичайну сторінку під час входу в адміністративну панель, тоді як користувачі з пошукової видачі або мобільних пристроїв потрапляють на сторонній ресурс.
Такі атаки не завжди проявляються постійно. Вірус може спрацьовувати лише для нових відвідувачів, певних країн, конкретних браузерів або за переходом із Google. Тому відсутність редиректу під час однієї перевірки ще не означає, що сайт безпечний.
Типові схеми шкідливих редиректів
Зловмисники використовують кілька поширених способів приховати перенаправлення:
- автоматичний перехід на інший домен одразу після відкриття сторінки;
- редирект лише з пошукових систем, рекламних кампаній або соціальних мереж;
- показ шкідливого коду тільки мобільним користувачам;
- відкладене перенаправлення після натискання, прокручування або певної кількості секунд;
- підміна окремих сторінок, наприклад головної, сторінки входу або сторінки оформлення замовлення;
- вбудовування невидимого iframe, скрипта чи зовнішнього рекламного коду.
Причиною може бути викрадений пароль адміністратора, вразливий плагін, заражена тема, небезпечний файл на хостингу або шкідливий запис у базі даних. Іноді редирект з’являється не на всіх сторінках, оскільки код запускається через умови, що перевіряють URL, cookie, user-agent або джерело переходу.
До початку очищення бажано створити копію файлів і бази даних у поточному стані. Навіть заражена копія може знадобитися для пошуку джерела проникнення. Водночас її не слід використовувати для відновлення без перевірки: повернення всіх файлів із такої копії може повторно активувати вірус.
Перевірка JavaScript і .htaccess
Перший етап перевірки — пошук сторонніх змін у файлах, які відповідають за формування сторінки та перенаправлення. Особливу увагу варто звернути на:
.htaccessу кореневій директорії та вкладених каталогах;- файли
index.php,wp-config.phpта файли активної теми; - JavaScript-файли з незрозумілими назвами або нещодавньою датою зміни;
- виклики зовнішніх доменів, обфускований код і конструкції на кшталт
eval,base64_decode,gzinflate; - невідомі PHP-файли в каталогах завантажень, кешу або тимчасових файлів.
У файлі .htaccess шкідливі правила можуть маскуватися серед стандартних директив WordPress. Підозрілими є незрозумілі умови з перенаправленням на чужий домен, правила для мобільних пристроїв, а також конструкції, що змінюють поведінку залежно від заголовків запиту.
Перевіряти код краще не через випадкове видалення рядків у редакторі хостингу, а порівнянням із чистою версією WordPress, теми або плагіна. Перед будь-якими змінами потрібно зберегти резервну копію. Помилка в .htaccess або PHP-файлі може спричинити помилку 500, втрату доступу до сайту чи некоректну роботу окремих функцій.
Заражені плагіни та тема
Вразливий або змінений плагін часто стає точкою входу для вірусу. Ризик підвищується, якщо розширення давно не оновлювалося, завантажене з неофіційного джерела, має nulled-ліцензію або більше не підтримується розробником.
Під час перевірки варто скласти перелік усіх активних і неактивних плагінів, визначити їхні версії та порівняти файли з оригінальними дистрибутивами. Важливо перевірити не лише активні розширення: шкідливий код може залишатися в неактивному плагіні або старій темі.
Безпечна послідовність для WordPress зазвичай передбачає:
- створення резервної копії файлів і бази даних;
- тимчасове обмеження доступу до сайту або переведення його в режим обслуговування;
- зміну паролів адміністратора, хостингу, FTP/SFTP і бази даних після перевірки пристрою на шкідливе програмне забезпечення;
- видалення невідомих плагінів і файлів;
- перевстановлення ядра WordPress, теми та розширень із надійних джерел;
- оновлення всіх компонентів до сумісних актуальних версій.
Не можна обмежуватися простим вимкненням підозрілого плагіна. Якщо зловмисник уже отримав доступ, він міг створити додаткового адміністратора, змінити файл теми, додати cron-завдання або залишити резервний механізм повторного зараження.
Якщо немає впевненості, який файл є оригінальним, або сайт містить важливі замовлення й персональні дані, краще залучити спеціаліста. Неправильне очищення може видалити корисний код, порушити роботу сайту або приховати справжню причину атаки.
Код у базі даних
Редирект може зберігатися не у файлах, а в базі даних. На WordPress шкідливі фрагменти часто додають до вмісту записів, налаштувань теми, віджетів, меню або таблиць із параметрами плагінів.
Підозрілими ознаками є:
- невідомі адміністратори та користувачі з підвищеними правами;
- скрипти в полях із текстом сторінок або віджетів;
- незнайомі значення в таблиці налаштувань;
- посилання на сторонні домени, приховані iframe та обфускований JavaScript;
- зміни, що відновлюються після очищення файлів.
Перед редагуванням бази даних обов’язково потрібна окрема резервна копія. Масова заміна через SQL-запит може пошкодити серіалізовані дані WordPress, зламати налаштування плагінів або видалити легітимний код. Спочатку потрібно визначити таблиці, де зберігається заражений фрагмент, і перевірити контекст його використання.
Окремо слід перевірити URL сайту, налаштування користувачів, шаблони листів, поля SEO-плагінів і код, який виводиться у заголовку або підвалі сторінки. Якщо база даних містить персональні дані клієнтів, її копії потрібно зберігати з обмеженим доступом і не передавати через незахищені канали.
Після очищення бажано перевірити журнали доступу хостингу, дату появи змін і список невдалих або підозрілих входів. Це допомагає зрозуміти, чи була проблема одиничною, чи зловмисник досі має доступ до сайту.
Контроль після очищення
Очищення не завершується видаленням знайденого скрипта. Потрібно повторно перевірити сайт із різних пристроїв і мереж, у режимі інкогніто, після очищення кешу браузера, CDN та серверного кешу. Варто протестувати не лише головну сторінку, а й форми, кошик, сторінку входу, мобільну версію та переходи з пошукової видачі.
Після відновлення слід:
- змінити всі паролі та відкликати непотрібні сесії;
- перевірити ролі користувачів і видалити невідомі облікові записи;
- оновити WordPress, тему, плагіни та серверне програмне забезпечення;
- увімкнути двофакторну автентифікацію для адміністративних акаунтів;
- перевірити права доступу до файлів і директорій;
- налаштувати регулярні резервні копії з перевіркою можливості відновлення;
- підключити моніторинг змін файлів і сповіщення про підозрілі входи.
Якщо редирект повертається після очищення, це може означати, що залишився прихований файл, шкідливий користувач, cron-завдання, заражений обліковий запис хостингу або вразливість, через яку сайт заражається повторно. У такій ситуації не варто нескінченно видаляти окремі рядки без повної діагностики.
Для складних випадків потрібне Відновлення сайту після зараження шкідливим кодом із перевіркою файлів, бази даних, доступів і серверного оточення. Результат залежить від масштабу зараження, стану резервних копій і того, чи вдалося закрити вразливість, через яку з’явився вірус.