Послуга

Технічний аудит WordPress, відновлення сайту після злому

Проєкт

Корпоративний WordPress-сайт міжнародної компанії в ніші засобів для захисту рук

Мета

— Видалення шкідливого коду, спамних публікацій, прихованих посилань і бекдорів; закриття вразливостей і відновлення нормальної роботи сайту

Регион

Велика Британія, Європа, США

Вихідні дані

Корпоративний сайт — це не просто «візитка в інтернеті». Для B2B-компанії він часто працює як точка входу для партнерів, дистриб’юторів, клієнтів і потенційних співробітників. Тому він має не лише нормально працювати, а ще й бути безпечним і контрольованим. Коли ж сайт починає жити своїм життям, публікувати казино-контент різними мовами та ховати підозрілі посилання в коді, це вже не «технічна дрібниця». Це повноцінне цифрове захоплення території, яке становить небезпеку для бізнесу та репутації.

Саме з такою проблемою WordPress-сайт потрапив до команди RegisTeam на технічний аудит. У статті-кейсі розповідаємо, які критичні наслідки злому ми виявили, як видалили шкідливий код і закрили вразливості, відновили нормальну роботу адмінки та допомогли клієнту повернути контроль над ресурсом.

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

  • автомобільної;
  • сільськогосподарської;
  • виробничої;
  • клінінгової;
  • харчової тощо.

Компанія працює на ринках Великої Британії, ЄС і США. Тобто сайт для неї — важлива частина присутності в кількох регіонах.

Клієнт звернувся із запитом на технічний аналіз. На корпоративному WordPress-сайті спостерігалися проблеми, потрібно було розібратися в ситуації та надати рекомендації.

На старті це звучало як класичний технічний аудит. Але ми швидко зрозуміли, що перед нами не просто застарілі плагіни чи «щось зламалося після оновлення». Сайт був зламаний.

Аналітика проєкту

Головна проблема була очевидною: сайт використовували зловмисники для публікації стороннього контенту.

У розділі «Блог» з’явилися десятки й сотні публікацій різними мовами з рекламою казино. Причому публікувалися вони не один раз, а з наполегливістю людини, яка дуже хоче перемогти в номінації «Спам року».

Крім цього, на сайті траплялися приховані та спамні посилання на інші ресурси. Це типова схема Black Hat SEO: зловмисники використовують репутацію чужого сайту, щоб просувати сторонні проєкти.

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

Критичні проблеми, які потрібно було вирішити насамперед

Після первинного аналізу ми виділили кілька критично важливих напрямів.

1. Сайт був зламаний і використовувався для публікації спаму

У блозі масово з’являлися пости з казино-контентом. Це шкодило не лише зовнішньому вигляду сайту, а й репутації домену.

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

2. На сайті були спамні посилання

Ми виявили посилання на сторонні ресурси, зокрема сайти казино та інші підозрілі домени. Вони були заховані у віджетах, контенті сторінок, серіалізованих JSON-даних метаполів Elementor.

Особливо неприємний момент: такі посилання часто не видно звичайному користувачеві. На сторінці все може виглядати нормально, але в коді сайт уже працює як безкоштовний рекламний майданчик для зловмисників.

3. Були ознаки прихованого доступу хакерів

Попередній аналіз показав наявність прихованого акаунта адміністратора з логіном wpadminyu.

Також був виявлений скрипт AdminConcealer, який приховував цей акаунт з адмінпанелі. Тобто користувач із повними правами існував, але звичайним способом його не можна було побачити.

Це якби в офісі була людина з ключами від усіх кабінетів, але в списку співробітників її не було. Дуже зручно, але тільки не для власника бізнесу.

4. Шкідливий код блокував оновлення та зміни

Ми виявили на сайті ознаки коду, який відключав можливість редагувати й оновлювати файли з адмінки через DISALLOW_FILE_MODS.

Також виявили фільтр:

add_filter(‘site_transient_update_plugins’, ‘__return_false’)

Він відключав сповіщення про оновлення плагінів, щоб власник сайту не бачив, що плагіни застаріли, і не закривав уразливості.

Це один із типових сценаріїв після злому: зловмисники не просто отримують доступ, а намагаються зберегти його якомога довше.

5. На сайті були підозрілі директорії та файли

У папці wp-content/plugins ми знайшли підозрілі папки:

  • pwnd;
  • prewdview-domwain.

Також підозру викликав файл hello.php. Його було переписано зі стандартного функціоналу Hello Dolly на шкідливий код (бекдор).

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

Чому не можна просто видалити «підозрілі файли» і заспокоїтися

Під час злому WordPress головна помилка — лікувати симптоми, а не причину.

Видалити кілька дивних файлів недостатньо, адже шкідливий код і доступи зловмисників до сайту можуть бути заховані в:

  • файлах теми;
  • плагінах;
  • базі даних;
  • cron-завданнях;
  • віджетах;
  • автозавантаженні WordPress;
  • старих копіях сайту;
  • кеші;
  • прихованих користувачах;
  • SSH-ключах;
  • змінених правах доступу.

Іноді бекдор виглядає не як очевидний вірусний файл, а як фрагмент коду, замаскований під звичайну функцію.

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

План робіт

Ми сформували пул завдань за кількома напрямами, коротко опишемо їх нижче.

Перевірка доступів

Потрібно було перевірити:

  • усі FTP-акаунти;
  • SSH- і SFTP-доступи;
  • ролі користувачів;
  • доступи на рівні хостингу;
  • cron-завдання;
  • підозрілі ключі та системні записи.

Пошук прихованого адміністратора

Окремо перевіряли наявність акаунта wpadminyu та коду, який міг приховувати його з адмінпанелі.

Також перевірили бази даних на сторонніх користувачів і підозрілі записи.

Очищення шкідливого коду

Особливу увагу приділили директоріям:

  • wp-content/plugins
  • wp-content/cache
  • wp-includes

Перевіряли підозрілі файли, порожні папки, старі копії, директорії з назвами на кшталт old, bak, _bak.

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

Відновлення нормальної роботи сайту

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

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

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

Завдання полягало не просто в тому, щоб «почистити сайт», а в тому, щоб повернути власнику контроль над ресурсом і знизити ризик повторної компрометації в майбутньому.

Дії команди

Роботи проводилися комплексно: на рівні хостингу, файлів сайту, бази даних, WordPress-адмінки та систем безпеки.

Видалили підозрілі доступи та оновили паролі

Ми видалили всіх FTP-користувачів з хостингу, змінили SSH/SFTP-паролі.

Також на хостингу ми виявили права доступу у двох неідентифікованих користувачів. Оскільки ми не могли підтвердити, що це легітимні акаунти, права було відкликано.

Після цього ми замінили доступи для всіх користувачів, які залишилися в системі.

Видалили сміттєві директорії та скомпрометований SSH-ключ

У кореневій директорії хостингу ми виявили директорії, які не потрібні для роботи сайту. Такі елементи могли бути залишені навмисно як точка для повторного доступу.

Також видалили SSH-ключ у файлах. За попередньою оцінкою, він міг бути скомпрометований.

Очистили базу даних від шкідливих посилань і записів

У базі даних ми виявили багато вірусних віджетів зі шкідливими посиланнями, наприклад:

  • heylink.me/officialpion138;
  • pusat777official.hair;
  • mez.ink/pusat777.

Основне навантаження було в рядках, пов’язаних із:

  • widget_block;
  • sidebars_widgets[footer-1];
  • автотемплейтами customize_changeset.

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

Видалили приховані та шкідливі файли

Було видалено:

  • public/wp-includes/SimplePie/library/SimplePie/york.php
  • public/wp-content/plugins/hello.php
  • wp-content/plugins/pwnd
  • wp-content/plugins/prewdview-domwain
  • public/wp-content/cache-OLD/
  • public/wp-content/cache/

Файл york.php ми класифікували як бекдор. Директорії pwnd і prewdview-domwain також видалили як сліди шкідливої активності.

Відновили пошкоджені файли

Було відновлено файли:

  • public/wp-config.php
  • public/wp-content/themes/twentytwentyone-child/functions.php

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

Видалили приховані спамні SEO-посилання

Ми знайшли та видалили прихований HTML-блок із display:none, який посилався на сайти з продажу реплік годинників:

  • thecomedypub.co.uk;
  • tickwatchtock.co.uk;
  • watchesfromme.co.uk.

Посилання були глибоко заховані в JSON-налаштуваннях Elementor у _elementor_data та в контенті сторінок усередині таблиці wp_posts.

Це хороший приклад того, чому поверхнева перевірка сайту не працює. Візуально сторінка може виглядати нормально, але всередині — цілий підпільний торговий центр посилань.

Провели ротацію Security Salts

Ми перегенерували ключі авторизації у wp-config.php.

Це критично важливий крок. Після ротації Security Salts усі активні сесії користувачів стають недійсними. Навіть якщо зловмисник був залогінений у момент зміни пароля, його cookie перестають працювати.

Без цього зміна пароля могла б не дати миттєвого ефекту.

Видалили підозрілу тему та старі архіви сайту

Ми видалили підозрілу тему-пустушку wl4r55n0, яка слугувала прихованим бекдором, а також позбулися директорії зі старими повними архівами сайту ai1wm-backups.

Це було особливо важливо, бо такі архіви можуть містити:

  • дампи бази даних;
  • конфігураційні файли;
  • доступи;
  • технічну інформацію;
  • структуру сайту.

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

Масово очистили блог від спам-публікацій

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

Відновили відображення оновлень плагінів

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

Виправили права доступу до файлів

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

Ми обмежили права доступу до конфігураційних файлів, зокрема wp-config.php, який містить дані для підключення до БД. Тепер доступ налаштований за принципом мінімально необхідних прав, що блокує один із типових векторів повторного зараження.

Це базовий, але дуже важливий захід безпеки. Навіть ідеально очищений сайт можна зламати повторно, якщо конфігураційні файли доступні «для всіх охочих».

Додали захист директорії uploads від виконання PHP-коду

Ми створили файл .htaccess у директорії public/wp-content/uploads/.htaccess з таким правилом:

<Files *.php>
Order Allow,Deny
Deny from all
</Files>

Цей захист блокує виконання PHP-файлів у директорії завантажень.

Чому це важливо? Якщо зловмисник спробує завантажити шкідливий PHP-скрипт під виглядом картинки або документа, сервер не зможе його виконати. Директорія uploads залишиться місцем для зберігання статичних файлів, а не майданчиком для запуску бекдорів.

Додаткові проблеми, які виявилися після очищення

Після усунення основної шкідливої активності ми продовжили перевірку сайту та виявили додаткові проблеми.

1. Публікація сторінок і завантаження медіафайлів

На сайті була порушена можливість публікувати нові сторінки та пости, а також завантажувати медіафайли.

Перша причина була пов’язана із Sucuri*: система безпеки блокувала REST API WordPress. Ми відключили опцію, яка заважала коректній роботі сайту, і додали фільтри, що дозволили ресурсу працювати нормально.

*Sucuri – плагін WordPress для захисту сайту.

2. Пошкоджена структура бази даних

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

Ми написали та застосували кастомний коригувальний SQL-скрипт. Він просканував 9 базових таблиць WordPress, зокрема:

  • wp_posts;
  • wp_postmeta;
  • wp_users;
  • wp_options та інші.

Скрипт переназначив коректні зв’язки Primary Key і AUTO_INCREMENT. Структуру таблиць було приведено до нормального стану WordPress.

3. Збереження товарів

Ми усунули проблему з неможливістю зберігати товари. Причина виявилася не у WooCommerce як такому, а у відсутності вільного місця на хостингу.

І тут ми вийшли ще на одну важливу проблему.

Чому база даних займала 55 ГБ?

У процесі роботи ми виявили, що база даних сайту розрослася до 55 ГБ. Основною причиною став WooCommerce Action Scheduler — вбудований планувальник фонових завдань інтернет-магазину.

Дві таблиці займали майже весь обсяг:

  • wp_actionscheduler_logs – 46 595 МБ;
  • wp_actionscheduler_claims – близько 800 МБ.

Що сталося?

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

Важливо: ці таблиці не містили замовлень, товарів або налаштувань магазину. Вони зберігали лише технічні логи й тимчасові дані. Тому ми повністю очистили їх, звільнивши місце та відновивши можливість нормальної роботи сайту.

Спроба повторного доступу після закриття бекдору

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

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

Тому комплексний захист після очищення — не додаткова опція, а обов’язкова частина роботи.

Результати

У межах комплексного очищення та відновлення сайту наші спеціалісти:

  • видалили приховані та підозрілі акаунти;
  • закрили неідентифіковані доступи на рівні хостингу;
  • змінили SSH-, SFTP- і користувацькі паролі;
  • видалили шкідливі файли та директорії;
  • відновили заражені файли wp-config.php і functions.php;
  • очистили базу даних від шкідливих посилань і записів;
  • видалили приховані спамні SEO-посилання з Elementor і wp_posts;
  • видалили понад 500 казино-публікацій;
  • відновили нормальний вигляд блогу;
  • повернули відображення оновлень плагінів;
  • виправили права доступу до критично важливих файлів;
  • видалили старі архіви сайту, які могли стати джерелом повторного злому;
  • додали захист директорії uploads від виконання PHP;
  • відновили публікацію сторінок і постів;
  • відновили завантаження медіафайлів;
  • виправили пошкоджену структуру бази даних;
  • очистили розрослі таблиці WooCommerce Action Scheduler;
  • звільнили місце на хостингу;
  • заблокували спробу повторного доступу через закритий бекдор.

У результаті сайт працює стабільно й залишається ефективним бізнес-інструментом, а клієнт знову має повний контроль над ним.

Що важливо зрозуміти власникам сайтів?

Злам сайту — це не завжди чорний екран із написом «Вас зламали». Іноді сайт продовжує працювати, відкриватися, приймати замовлення й виглядати майже нормально.

Але всередині можуть відбуватися речі, які шкодять бізнесу:

  • публікується спам-контент;
  • з’являються приховані посилання;
  • створюються приховані користувачі;
  • відключаються оновлення;
  • ламається база даних;
  • зростають технічні логи;
  • погіршується репутація домену;
  • зловмисники зберігають можливість повернутися.

Тому технічна підтримка сайту — це не лише «оновити плагін раз на місяць». Це регулярний контроль безпеки, доступів, файлів, бази даних, хостингу та поведінки сайту.

Підсумки

У цьому проєкті ми зіткнулися не з однією проблемою, а з цілим ланцюгом наслідків злому: прихований адміністратор, шкідливий код, бекдори, спамні публікації, SEO-посилання, пошкоджена база даних, забитий логами хостинг і спроба повторного доступу.

Команда RegisTeam провела глибокий технічний аналіз, усунула знайдені вразливості, очистила сайт від шкідливого коду та відновила нормальну роботу WordPress.

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

Хочете переконатися, що ваш сайт належить тільки вам, а не використовується зловмисниками для їхніх темних справ? Залишайте заявку вже зараз: проведемо комплексну перевірку та «виженемо непроханих гостей», якщо вони є, без можливості повернення.