Якщо з вашого хостингу почали надходити скарги на спам, це не завжди означає, що проблема саме у WordPress. Причиною може бути зламаний обліковий запис адміністратора, вразливий плагін, викрадений пароль до пошти, шкідливий PHP-скрипт або скомпрометована поштова форма.
Таку ситуацію важливо розглядати як інцидент безпеки, а не просто як технічний збій. Навіть після видалення шкідливого файлу сайт може залишатися зараженим, а домен, IP-адреса чи поштовий акаунт — мати низьку репутацію. Перед небезпечними діями бажано створити резервну копію файлів і бази даних. Вона може містити шкідливий код, але без неї є ризик втратити матеріали або важливі докази зараження.
Як підтвердити несанкціоновану розсилку
Спочатку потрібно з’ясувати, чи справді листи надсилаються з вашого хостингу, а не лише імітують адресу вашого домену. Зловмисники можуть підробляти поле відправника, використовуючи ваш домен у заголовках листа, хоча самі повідомлення відправляються з іншого сервера.
Перевірте такі джерела інформації:
- журнали поштового сервера та панелі хостингу;
- чергу вихідних повідомлень і статистику відправлення;
- час, обсяг і тип повідомлень, які надсилаються;
- сповіщення хостинг-провайдера про перевищення лімітів;
- звіти про недоставку, скарги одержувачів і блокування IP-адреси;
- заголовки отриманих спам-листів, зокрема поля
Received,Return-Pathта результати SPF, DKIM і DMARC.
Якщо в логах видно масові виклики PHP-пошти, незвичні SMTP-підключення або активність від невідомого скрипта, імовірність компрометації висока. Водночас просте очищення черги не усуває причину: шкідливий код може продовжити створювати нові повідомлення.
Де шукати поштові скрипти та бекдори
Заражений сайт не обов’язково містить файл із назвою на кшталт spam.php. Бекдор часто маскується під системний файл WordPress, плагін, тему або службовий компонент. Підозрілими можуть бути файли, змінені незадовго до початку розсилки, а також PHP-файли в каталогах, де їм зазвичай не місце.
Під час перевірки зазвичай аналізують:
- каталоги
wp-content/uploads, кешу та тимчасових файлів; - нещодавно змінені файли ядра, тем і плагінів;
- файл
wp-config.phpта правила у.htaccess; - записи в таблицях користувачів, налаштувань і запланованих завдань;
- активні плагіни, теми та невідомі адміністративні облікові записи;
- завдання cron, які запускають сторонні PHP-скрипти;
- поштові форми, SMTP-налаштування та сторонні інтеграції.
Окрему увагу приділяють конструкціям на кшталт eval, base64_decode, gzinflate, динамічному виконанню коду та незрозумілим довгим рядкам. Самі по собі окремі такі функції не доводять зараження, оскільки їх можуть використовувати легальні компоненти. Видалення файлів лише за назвою або одним підозрілим фрагментом може пошкодити сайт і не прибрати прихований доступ.
Безпечніше порівнювати файли ядра WordPress із чистою версією тієї самої редакції, перевіряти плагіни з офіційних джерел і аналізувати зміни в контексті логів. Якщо доступ до файлів обмежений або зараження повторюється, потрібна допомога спеціаліста з аналізу журналів, бази даних і серверного оточення.
Як зупинити спам без втрати сайту
Першочергове завдання — припинити відправлення, але зробити це так, щоб не знищити потрібні дані. Перед змінами створіть копію файлів і бази даних, зафіксуйте час інциденту, збережіть логи та не перезаписуйте єдину копію доказів.
- Тимчасово вимкніть функцію відправлення пошти на рівні хостингу або обмежте PHP-розсилку, якщо це не зупиняє критично важливі процеси.
- Призупиніть підозрілий cron або конкретний скрипт лише після перевірки його призначення.
- За необхідності переведіть сайт у режим обслуговування, щоб унеможливити повторне використання вразливого функціоналу.
- Заблокуйте скомпрометовані облікові записи та відкликавте невідомі сесії, токени й ключі доступу.
- Оновіть WordPress, теми та плагіни після створення резервної копії й перевірки сумісності.
- Замініть заражені компоненти на чисті копії з надійного джерела, а не просто редагуйте підозрілий код вручну.
Не варто одразу видаляти всю папку сайту, очищати базу даних або відновлювати невідомий резервний архів поверх поточних даних. Резервна копія могла бути створена вже після зараження. Крім того, масове видалення може призвести до втрати замовлень, записів клієнтів, медіафайлів і налаштувань.
Після локалізації інциденту потрібно перевірити не лише WordPress, а й усі сайти в тому самому хостинг-акаунті. Якщо вони використовують спільний користувач, каталог або пароль, зараження могло поширитися між ними.
Відновлення паролів і поштової репутації
Паролі слід змінювати після очищення або паралельно з ним, якщо є підозра, що зловмисник досі має доступ. Інакше новий пароль може бути викрадений повторно. Змініть доступи до:
- адміністративних облікових записів WordPress;
- панелі хостингу, FTP, SFTP, SSH і бази даних;
- поштових скриньок та SMTP-сервісів;
- реєстратора домену, CDN і зовнішніх інтеграцій;
- сервісів аналітики, платіжних систем і рекламних кабінетів.
Використовуйте унікальні складні паролі та двофакторну автентифікацію, де вона доступна. Видаліть невідомих користувачів, застосунки, API-ключі та активні сесії. Перевірте, чи не змінилися адреси для відновлення доступу, SMTP-параметри, правила пересилання пошти та права користувачів.
Для захисту домену налаштуйте SPF, DKIM і DMARC відповідно до фактичної схеми відправлення. Ці записи не очистять заражений сайт, але допоможуть поштовим системам відрізняти дозволені повідомлення від підроблених. Якщо домен або IP уже потрапив до блок-листів, потрібно з’ясувати причину, припинити розсилку та звернутися до хостинг-провайдера або відповідного оператора блокування. Видалення з блок-листа не завжди відбувається автоматично.
Не збільшуйте обсяг відправлення одразу після очищення. Спочатку перевірте доставлення на тестових адресах, коректність DNS-записів, підписи DKIM і відсутність нової підозрілої активності.
Контроль після очищення
Очищення вважається завершеним не в момент видалення одного шкідливого файла, а після перевірки всієї ланки: сайту, хостингу, поштових облікових записів і доступів. Протягом наступних днів контролюйте логи, чергу пошти, навантаження на сервер, створення нових файлів і зміни в адміністративній панелі.
- Перевіряйте, чи не з’являються нові невідомі PHP-файли.
- Контролюйте заплановані завдання та активність користувачів.
- Переглядайте звіти SPF, DKIM і DMARC.
- Слідкуйте за повідомленнями хостингу про перевищення лімітів.
- Перевіряйте сайт сканером безпеки та вручну аналізуйте результати.
- Створюйте окремі перевірені резервні копії за розкладом і тестуйте їх відновлення.
Якщо спам поновлюється, сайт продовжує перенаправляти відвідувачів, з’являються невідомі адміністратори або змінюються файли після очищення, не варто нескінченно видаляти симптоми. Це може свідчити про прихований бекдор, скомпрометований серверний акаунт або вразливість, яку ще не усунуто.
У такій ситуації потрібна повна технічна діагностика: аналіз логів і резервних копій, перевірка файлів та бази даних, відновлення доступів, оновлення компонентів і налаштування контролю змін. Відновлення репутації залежить від масштабу розсилки, стану домену, IP-адреси та поштової інфраструктури, тому оцінити результат можна лише після перевірки конкретного сайту.