Услуга

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

Проект

Корпоративный сайт WordPress международной компании в нише средств для защиты рук

Цель

— Удаление вредоносного кода, спамных публикаций, скрытых ссылок и бэкдоров; закрытие уязвимостей и восстановление нормальной работы сайта

Регион

Великобритания, Европа, США

Исходные данные

Корпоративный сайт – это не просто “визитка в интернете”. Для B2B-компании он часто работает как точка входа для партнеров, дистрибьюторов, клиентов и потенциальных сотрудников. Поэтому он должен не только нормально работать, но еще быть безопасным и контролируемым. Когда же сайт начинает жить своей жизнью, публиковать казино-контент на разных языках и прятать подозрительные ссылки в коде, это уже не “техническая мелочь”. Это полноценный цифровой захват территории, что представляет опасность для бизнеса и репутации.

Именно с такой проблемой к команде RegisTeam попал сайт на WordPress на технический аудит. В статье-кейсе рассказываем, какие критические последствия взлома мы выявили, как удалили вредоносный код и закрыли уязвимости, тем самым восстановили нормальную работу админки и помогли клиенту вернуть контроль над ресурсом.

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

  • автомобильной;
  • сельскохозяйственной;
  • производственной;
  • клининговой;
  • пищевой и пр.

Компания работает на рынках Великобритании, ЕС и США. То есть сайт для нее – важная часть присутствия в нескольких регионах.

Клиент обратился с запросом на технический анализ. На корпоративном сайте 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 – дополнение WP для защиты сайта.

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 и репутации бренда.

Хотите убедиться, что ваш сайт принадлежит только вам, а не используется злоумышленниками для их темных дел? Оставляйте заявку уже сейчас: проведем комплексную проверку и “выгоним непрошенных гостей”, если они есть, без возможности возвращения.