Когда мы принимали в работу сайт стоматологической клиники, он открывался и выглядел нормально. Страницы были на месте, вход в WordPress работал. Но при проверке сервера мы нашли вредоносные скрипты, скрытый код в папке плагина и семь подозрительных администраторов.
Ниже рассказываем, как обнаружили взлом и очистили сайт. А ещё разбираем 12 признаков, по которым владелец или специалист может заметить похожую проблему.
Как обычная проверка доступов превратилась в расследование
После передачи проекта мы проверили доступы, а затем перешли к файлам и настройкам сервера.
В системных папках WordPress обнаружились файлы, которых нет в официальном дистрибутиве. Рядом лежал файл настроек .htaccess: он разрешал серверу выполнять скрипты с нестандартным расширением.
Мы изучили их содержимое. Скрипты принимали команды извне и запускали их на сервере. Это были бэкдоры, то есть скрытые способы доступа к сайту.
На этом проверку не остановили. В глубине папки одного из плагинов нашли ещё один вредоносный файл размером около 538 КБ. Он содержал закодированный блок, который подключался и выполнялся как PHP-код. Затем проверили пользователей WordPress и обнаружили семь подозрительных учётных записей с правами администратора.
Чтобы разобраться в истории заражения, сопоставили находки с датами файлов и журналами обращений. Метаданные указывали на изменения в конце июня, а в августовских журналах были запросы к характерным адресам закладок. Вредоносные файлы сохранились даже после обновления WordPress.
Так мы подтвердили наличие закладок и лишних административных доступов. Установить первоначальную точку входа по собранным данным не удалось. Даты файлов тоже не доказывают точный день взлома: их можно изменить.
12 признаков, которые помогают обнаружить взлом
Первые четыре признака мы обнаружили на этом проекте. Остальные включили в чек-лист для проверки других сайтов.
1. В админке появились неизвестные администраторы
У каждой учётной записи с полными правами должен быть понятный владелец. Незнакомый пользователь может оказаться старым подрядчиком, поэтому сначала нужно выяснить, кто и зачем его создал.
В нашем случае после проверки удалили семь подозрительных администраторов, оставив необходимые рабочие доступы.
2. В системных папках лежат посторонние файлы
Новые скрипты и неизвестные каталоги внутри ядра WordPress требуют проверки. У нас штатные файлы проходили сверку с оригиналом, но рядом с ними находились вредоносные.
Для сравнения файлов ядра с официальным дистрибутивом подходит проверка контрольных сумм WordPress. Плагины, темы, загрузки и базу данных нужно проверять отдельно.
3. В папке плагина или темы спрятан непонятный код
Повод присмотреться: неизвестный PHP-файл среди изображений и стилей, длинные закодированные блоки, код, который загружает или выполняет другое содержимое.
Именно так выглядела одна из наших находок. При этом сам факт кодирования ещё не доказывает заражение. Нужно разбирать действия программы. А расположение закладки в папке плагина не доказывает, что сайт взломали через этот плагин.
4. Без вашего ведома изменились настройки сервера
В .htaccess могут появиться чужие перенаправления или правила, которые разрешают запускать файлы с необычными расширениями.
В нашем случае такие настройки обеспечивали работу вредоносных скриптов. Поэтому при очистке мы проверяли и сами закладки, и правила их запуска.
5. В папке загрузок появились исполняемые скрипты
Каталог с фотографиями и документами стоит проверить на неизвестные программы. Одного просмотра расширений недостаточно: возможность запуска зависит и от настроек сервера.
При очистке нашего проекта мы отдельно проверили загрузки и запретили выполнение опасных типов файлов в этой папке.
6. В поиске появились страницы, которые никто не публиковал
Например, сайт клиники находится по запросам про казино или чужие товары. Проверка начинается с конкретных адресов: что на них открывается, откуда взялось содержимое, есть ли оно в админке.
Незнакомый URL может оказаться старой страницей или дублем. Длинный адрес и окончание -2 сами по себе не говорят о взломе.
7. Посетителей перенаправляет на посторонние сайты
Владелец видит обычную страницу, а человек из поиска попадает на рекламу или другой ресурс. Поэтому полезно сравнить переходы из поиска и прямое открытие сайта, проверить его на телефоне и без авторизации.
Такие перенаправления описаны в справке Google о безопасности.
8. Браузер, поисковик или хостинг сообщает об угрозе
Уведомление нужно проверить: какой файл или адрес вызвал срабатывание, что именно обнаружено.
В Google Search Console для этого есть раздел «Проблемы безопасности». Он может показывать примеры заражённых страниц, но их список не обязательно полный. Отсутствие предупреждений также не подтверждает чистоту сервера.
9. Появились неизвестные задания по расписанию
Фоновые задачи используются для резервных копий, уведомлений и обновлений. Подозрение вызывают задания, назначение которых никто не может объяснить, особенно если они запускают неизвестный файл.
Проверять нужно и задачи WordPress, и расписание в панели хостинга. Это разные списки.
10. Сервер создаёт необъяснимую нагрузку или рассылает посторонние письма
Сайт тормозит без роста посещаемости, хостинг жалуется на рассылку, расход ресурсов резко увеличился.
Причиной может быть как вредоносная программа, так и ошибка плагина или тяжёлая резервная копия. Разобраться помогают журналы и проверка процессов: какой файл запущен и что он делает.
11. В журналах есть обращения к подозрительным скриптам
На нашем проекте такие запросы были. Найденные закладки до очистки также были доступны по HTTP.
Но обращение бота к несуществующему файлу не означает успешный взлом. Даже ответ 200 OK не доказывает выполнение команды. Запросы нужно сопоставлять с содержимым файлов и другими событиями на сервере.
12. После удаления чужие файлы или страницы появляются снова
Это повод искать сохранившийся доступ: другую закладку, неизвестного администратора, фоновую задачу или украденные учётные данные.
Если удалять только появляющийся файл, проблема может повторяться. Нужно выяснить, кто или что его восстанавливает.
По этому списку удобно собрать вопросы для проверки. Число совпадений не определяет диагноз: взлом подтверждают конкретные файлы, действия и изменения.
Как мы очистили сайт
Сначала сохранили материалы расследования. Вредоносные файлы перенесли в закрытый карантин за пределами публичной папки сайта. Туда же сохранили исходные настройки и сведения о файлах. Перед удалением пользователей сделали копию базы.
Такой порядок позволяет не потерять доказательства и проверить изменения, если после восстановления что-то пойдёт не так. Сохранение состояния сайта перед очисткой рекомендует и инструкция WordPress после взлома.
Затем восстановили файлы сайта: переустановили ядро WordPress из официального пакета, заменили заражённый плагин штатным обновлением и убрали старый неиспользуемый каталог другого плагина. Обновили компоненты, для которых были доступны пакеты. Коммерческие плагины с ограничениями обновления не стали считать обновлёнными.
После этого удалили семь подозрительных администраторов, завершили старые сессии оставленных пользователей и сменили секретные ключи WordPress для авторизации. Смена этих ключей не заменяет смену паролей.
Защиту файлов усилили отдельно:
- запретили выполнение скриптов в папке загрузок;
- ограничили загрузку опасных типов файлов;
- отключили редактирование файлов через админку;
- ограничили доступ к конфигурационным и служебным файлам;
- отключили ненужную регистрацию пользователей.
Эти настройки уменьшают возможности для повторного заражения. Они работают вместе с обновлениями и контролем доступов, как описано в рекомендациях по защите WordPress.
Что показала повторная проверка
После очистки файлы ядра прошли сверку с официальными контрольными суммами. Известные адреса закладок возвращали 404, главная страница и вход в WordPress работали. Повторный поиск не обнаружил ранее найденных вредоносных файлов и проверенных признаков заражения.
База данных также прошла проверку структуры. Этот результат подтверждает её техническую исправность, но сам по себе ничего не говорит об отсутствии вредоносного содержимого.
Мы подтвердили удаление обнаруженных закладок и работоспособность сайта после изменений. Для полного закрытия инцидента отдельно проверяют смену скомпрометированных доступов, задачи хостинга и состояние всех компонентов. Одной успешной проверки ядра для этого недостаточно.
С чего начать, если вы заметили похожие признаки
Для обращения к специалисту или в поддержку хостинга полезно собрать конкретные примеры: адрес подозрительной страницы, скриншот предупреждения, время перенаправления, имя неизвестного пользователя. Затем сохранить журналы и копию текущего состояния сайта отдельно от заведомо чистых резервных копий.
Если сайт уже перенаправляет посетителей или распространяет вредоносный контент, доступ к опасным страницам нужно оперативно ограничить. Массовое удаление файлов наугад может сломать сайт и уничтожить следы, которые помогли бы разобраться.
В нашем случае до проверки сайт продолжал открываться. Закладки обнаружились при сравнении файлов, изучении настроек и проверке администраторов. Поэтому при приёмке проекта мы проверяем не только доступность страниц, но и то, что находится на сервере.