Після злому WordPress повертається шкідливий код: як знайти бекдор

Повторне зараження WordPress часто виглядає так: після очищення сайт працює нормально, але через кілька годин або днів знову з’являються сторонні файли, перенаправлення, спам-посилання, невідомі користувачі чи підозрілі адміністративні дії. Зазвичай це означає, що під час першого очищення не було видалено бекдор або не усунуто вразливість, через яку зловмисник отримує доступ повторно.

Бекдор — це прихований механізм доступу до сайту. Він може бути невеликим фрагментом PHP-коду, замаскованим файлом, шкідливим записом у базі даних або додатковим обліковим записом адміністратора. Нижче наведено безпечну послідовність перевірки, але перед будь-якими змінами бажано створити резервну копію файлів і бази даних. Якщо копія вже містить зараження, її не слід без перевірки використовувати для відновлення робочого сайту.

Чому зараження з’являється повторно

Найпоширеніша причина — видалення видимого прояву атаки без пошуку її джерела. Наприклад, адміністратор прибирає один заражений файл, але в іншій директорії залишається скрипт, який створює його знову. Так само очищення головної сторінки не допоможе, якщо шкідливий код зберігається в базі даних або виконується через планувальник завдань.

• Не усунено вразливість. Застарілий WordPress, плагін або тема можуть дозволяти повторне завантаження файлів чи виконання стороннього коду.
• Залишився бекдор. Шкідливий файл може мати звичайну назву та перебувати серед легітимних файлів плагіна.
• Скомпрометовані паролі. Якщо зловмисник має доступ до адміністративної панелі, FTP, хостингу або бази даних, він може повторити атаку після очищення.
• Заражена резервна копія. Відновлення з інфікованого архіву повертає шкідливий код разом із сайтом.
• Залишилися сторонні облікові записи. Додатковий адміністратор або користувач із підвищеними правами може використовуватися для повторного входу.

Важливо перевіряти не лише сам сайт, а й середовище навколо нього: панель хостингу, поштові скриньки адміністраторів, FTP/SFTP-доступ, базу даних і журнали подій. Якщо після зміни пароля зараження повертається, проблема може бути не в паролі, а в активному бекдорі.

Де найчастіше ховаються бекдори

Бекдор не обов’язково має назву на кшталт hack.php. Часто він маскується під системний файл, додається до легітимного коду або розміщується в директорії, яку власник рідко перевіряє.

• wp-content/uploads. У цій директорії зазвичай зберігаються зображення та інші завантаження, але за неправильної конфігурації туди можуть потрапити PHP-файли.
• Теми та плагіни. Зміни можуть бути внесені до functions.php, файлів шаблону, службових бібліотек або коду плагіна.
• Каталоги wp-admin і wp-includes. Незнайомі або змінені файли в цих директоріях потребують порівняння з оригінальною версією WordPress.
• Коренева директорія сайту. Варто перевірити wp-config.php, .htaccess, індексні файли та файли з нетиповими назвами.
• Тимчасові та кеш-директорії. Залежно від хостингу там можуть залишатися скрипти, які запускаються повторно.
• База даних. Шкідливі вставки трапляються в записах, налаштуваннях, віджетах, меню та полях метаданих.

Підозрілим є не лише незнайомий файл, а й незвичний код у відомому файлі. Особливу увагу привертають конструкції з eval, base64_decode, gzinflate, assert, динамічним підключенням файлів та довгими зашифрованими рядками. Сам факт наявності такої функції ще не доводить зараження, тому рішення потрібно приймати після порівняння з оригінальним кодом і аналізу контексту.

Для технічної перевірки зручно використовувати контрольні суми файлів, антивірусний сканер на рівні хостингу та порівняння чистих копій WordPress, тем і плагінів. Не варто автоматично видаляти всі файли, які сканер позначив як підозрілі: це може пошкодити сайт або стерти потрібні дані.

Як перевірити базу cron і облікові записи

Навіть після очищення файлів шкідливий код може запускатися за розкладом. У WordPress для цього використовується WP-Cron, а на сервері можуть працювати системні cron-завдання. Бекдор через такий механізм періодично створює заражені файли, надсилає спам або змінює налаштування сайту.

1. Увійдіть до панелі керування WordPress із перевіреного пристрою та перегляньте заплановані події за допомогою інструмента керування cron.
2. Зверніть увагу на завдання з незрозумілими назвами, надто частим запуском або викликом невідомих функцій.
3. Перевірте системні cron-завдання в панелі хостингу або зверніться до адміністратора сервера.
4. Зіставте підозрілі події з часом появи нових файлів, перенаправлень чи змін у базі даних.
5. Перед видаленням зробіть копію поточних налаштувань і переконайтеся, що завдання не належить важливому плагіну або сервісу.

Окремо потрібно перевірити користувачів WordPress. У списку не повинно бути невідомих адміністраторів, редакторів або користувачів із непропорційно високими правами. Перегляньте дату створення облікових записів, електронні адреси та журнали входів. Після підтвердження компрометації невідомі облікові записи слід заблокувати або видалити, але спочатку варто зафіксувати інформацію для подальшого аналізу.

Паролі потрібно змінювати комплексно: для WordPress, хостингу, бази даних, FTP/SFTP, пошти та панелі керування доменом. Нові паролі мають бути унікальними, а доступ до адміністративної панелі бажано додатково захистити двофакторною автентифікацією та обмеженням за IP, якщо це підтримує інфраструктура.

Якщо ознаки злому зберігаються, може знадобитися відновлення WordPress після повторного зараження з аналізом файлів, бази даних, доступів і серверних журналів, а не лише поверхневе видалення окремих вставок.

Видалення шкідливого коду та вразливості

Очищення слід проводити на ізольованій копії або в режимі технічного обслуговування, щоб не втрачати зміни та не дозволяти відвідувачам працювати з пошкодженим сайтом. Перед початком збережіть резервні копії файлів і бази даних окремо від робочого сервера. Якщо діяти без резервної копії, помилка під час видалення може призвести до втрати контенту, налаштувань або працездатності сайту.

1. Зафіксуйте симптоми зараження, час їх появи та список змінених файлів.
2. Перевірте журнали сервера, входів до WordPress, FTP/SFTP і панелі хостингу.
3. Замініть ядро WordPress на чисту копію тієї самої або сумісної версії.
4. Перевстановіть теми та плагіни з офіційних або перевірених джерел, попередньо перевіривши сумісність.
5. Перевірте користувачів, cron-завдання, конфігураційні файли та базу даних.
6. Оновіть усі компоненти та видаліть непотрібні плагіни, теми й облікові записи.
7. Змініть усі скомпрометовані паролі та відкличте старі сесії доступу.

Не можна просто замінювати файли навмання або очищати базу даних масовою командою. У ній можуть зберігатися записи, замовлення, налаштування та дані клієнтів. Перед SQL-змінами потрібна окрема копія бази, а небезпечні запити краще виконувати лише після перевірки структури таблиць.

Якщо зараження пов’язане зі старим плагіном або темою, недостатньо видалити шкідливий фрагмент. Потрібно усунути саму вразливість: оновити компонент, замінити його на підтримуваний аналог або повністю видалити. Для сайтів із критичними даними бажано спочатку створити тестову копію та перевірити на ній роботу магазину, форм, інтеграцій і платежів.

Спеціаліст потрібен, коли немає доступу до хостингу або бази даних, зараження повертається після кількох очищень, змінено багато файлів, є ознаки витоку даних або сайт використовує складні інтеграції. Без діагностики неможливо достовірно визначити обсяг пошкоджень і безпечно оцінити, які дані можна зберегти.

Як контролювати сайт після ремонту

Після очищення сайт не варто одразу вважати безпечним. Потрібен період спостереження та контроль змін. Увімкніть журналювання входів і дій адміністраторів, відстежуйте появу нових файлів, зміни системних налаштувань і створення користувачів.

• Перевіряйте цілісність ядра WordPress та встановлених компонентів.
• Контролюйте зміни в wp-config.php, .htaccess і директорії завантажень.
• Регулярно переглядайте cron-події та список адміністраторів.
• Налаштуйте резервне копіювання з кількома версіями та зберігайте копії окремо від сервера.
• Перевіряйте, чи відкриваються сторінки без перенаправлень, спаму та підозрілих скриптів.
• Своєчасно встановлюйте оновлення WordPress, плагінів і тем після перевірки сумісності.

Резервні копії потрібно періодично тестувати: наявність архіву ще не означає, що з нього можна коректно відновити сайт. Також важливо обмежити права користувачів, вимкнути непотрібний доступ до файлів і бази даних, налаштувати HTTPS та захистити адміністративну панель.

Якщо шкідливий код з’являється знову, не слід нескінченно видаляти окремі файли. Це сигнал провести повну перевірку ланцюжка доступів, серверних завдань, бази даних і журналів. Такий підхід допомагає не лише прибрати наслідки злому, а й зрозуміти, через який канал атака повторюється.