Сайт взломали: что делать в первые часы и почему бэкап может не спасти

Иногда взлом видно сразу: вместо главной страницы висит чужая надпись вроде «Hacked by…». Но громкие случаи — меньшинство. Тому, кто взломал сайт, выгоднее, чтобы владелец ничего не заметил: тогда можно подольше показывать посетителям рекламу, уводить их на чужие сайты или заражать их компьютеры.

Признаки, на которые стоит обратить внимание:

• на сайте появилась чужая надпись, картинка или страница;
• поиск или браузер предупреждает, что сайт может быть опасен;
• хостинг прислал письмо о вредоносном коде или ограничил работу сайта;
• посетители жалуются, что их перебрасывает на другие сайты, чаще с телефона или из поиска, а у вас всё открывается нормально;
• сайт показывает проверку «Я не робот», которую вы не ставили, и просит что-то нажать на клавиатуре;
• в поиске появились страницы вашего сайта, которых вы не создавали, часто на чужом языке;
• в админке есть пользователи, которых никто не помнит;
• с вашего домена уходит спам, и письма компании начинают попадать в спам у получателей.

Если сайт не обновляли больше года, отсутствие признаков ещё ничего не значит. В разобранном нами случае на двух сайтах на Joomla первые следы взлома датированы 5 июля, а владелец забеспокоился только осенью, когда на одном сайте появилась надпись хакеров.

Этой осенью было две показательные истории.

Helix3. Это основа для шаблонов сайтов на Joomla. 29 июня 2026 года её разработчик выпустил исправление опасной дыры: через неё любой человек без пароля мог записывать файлы на сайт и менять код шаблона. Примерно через неделю, с 5 июля, начались массовые взломы. Обновиться успели не все. Те, кто не успел, получили на сайты «гостей» из разных хакерских групп.

PHP2Shell. Это две уязвимости в самом PHP — языке, на котором работают WordPress, 1С-Битрикс, Joomla и большинство сайтов на готовых движках. Исправление вышло 21 октября, а первую попытку атаки специалисты заметили ещё 17-го. Из-за этих уязвимостей в Европе отключали государственные сайты. Мы проверяли на неё интернет-магазин, который сопровождаем.

Обе истории устроены одинаково. Дыру находят, исправление выходит, и с этого момента начинается гонка: роботы ищут сайты, где исправление не поставили. Для владельца сайта это значит простую вещь: опасно не время, а необновлённый сайт.

Порядок важен. Самая частая ошибка — сразу начать удалять подозрительное и откатывать сайт. Так пропадают следы, по которым можно понять, как именно зашли, а дыра остаётся открытой.

1. Сохраните сайт как есть. Скопируйте файлы и базу данных в отдельное место, вместе со всем заражённым. Это доказательство и карта взлома: по датам файлов видно, когда и как сайт взломали.
2. Остановите вред посетителям. Если сайт показывает фальшивые проверки, уводит людей на чужие страницы или раздаёт вирусы, закройте его заглушкой «ведутся работы» или уберите вредоносный код. Каждый лишний час работы такого сайта — новые заражённые посетители.
3. Закройте вход. Найдите, через что зашли, и перекройте это место. Если не закрыть, всё вычищенное вернётся: на одном из сайтов, которые мы разбирали, новые файлы взломщиков появлялись и через месяц после восстановления.
4. Смените пароли с чистого компьютера. Хостинг, панель управления, FTP, база данных, администраторы сайта. Включите двухфакторный вход везде, где он есть.
5. Уберите из открытого доступа всё лишнее. Архивы сайта, копии файлов, служебные программы разработчиков. На одном из сайтов клиента полный архив сайта лежал в корне и скачивался по прямой ссылке. В таких архивах бывают пароли от базы данных.
6. Предупредите тех, кто мог пострадать. Если сайт заражал компьютеры посетителей, сотрудникам и клиентам, которые на него заходили, стоит проверить свои устройства. Что делать, если человек уже выполнил «проверку на робота», — в отдельной статье.

Хостинг в первый час тоже может помочь: например, временно закрыть сайт или включить свой антивирус. Но вылечить сайт за вас он, как правило, не возьмётся — это работа с кодом самого сайта.

Резервная копия спасает, только если она сделана до взлома. А хостинг обычно хранит копии за последние недели, а не месяцы.

Вот как это выглядело на одном из сайтов клиента, который обратился к нам 5 ноября:

Все копии были сделаны с заражённого сайта. После отката надпись хакеров исчезла, и казалось, что всё позади. Но вредоносный код в базе данных и файлы взломщиков остались, а дыра, через которую зашли, осталась открытой.

Есть и вторая причина. Часть современного вредоносного кода хранится не в файлах, а в базе данных — например, в настройках шаблона. Так устроена и атака на Helix3. Антивирус, который проверяет только файлы, такой код не увидит.

Лечение — это не поиск «вируса» одной программой, а несколько шагов, которые закрывают взлом целиком.

1. Найти вход. Понять, через какую дыру зашли: устаревший движок, плагин, шаблон, утёкший пароль, сосед по хостингу. Без этого лечение бесполезно.
2. Сверить каждый файл с оригиналом. У движка и расширений есть официальные дистрибутивы. Всё, что от них отличается или чего в них нет, проверяется вручную.
3. Очистить базу данных. Настройки шаблона, страницы, пользователи, служебные задания — везде, где может лежать чужой код или чужой администратор.
4. Обновить и закрыть. Обновить уязвимые части, выключить ненужные расширения, закрыть админку дополнительной защитой.
5. Проверить снаружи. Открыть сайт как обычный посетитель, с телефона и компьютера, из поиска. Часть вредоносного кода показывается не всем.
6. Наблюдать. Повторное заражение обычно проявляется в первые недели. Поэтому после лечения сайт нужно наблюдать, а не просто сдать работу.

• Обновлять не только движок. Шаблоны и плагины ломают чаще, чем сам движок, а обновляются они отдельно.
• Знать, на какой версии PHP работает сайт. Не «на сервере», а у конкретного сайта: в панели хостинга версию выбирают для каждого сайта отдельно, и она может отличаться от той, что видит администратор в командной строке. На одном сервере мы насчитали три разные версии.
• Помнить о соседях. Если на одном аккаунте хостинга живут несколько сайтов, взлом самого старого из них может открыть доступ ко всем остальным.
• Не держать в открытой папке сайта лишнего. Архивы, копии файлов с окончаниями вроде .bak или .old, тестовые скрипты, служебные программы.
• Включить двухфакторный вход в панель хостинга и админку.
• Планировать переезд, когда движок перестал получать обновления. Например, Joomla 3 не поддерживается с августа 2023 года. Чем дольше на ней работает сайт, тем больше в ней дыр, которые уже никто не закроет.

Сайты, которые мы делаем сами, устроены иначе. Почему массовые атаки на движки их обычно не затрагивают и где у них свои слабые места — в отдельном разборе.

Мы лечим взломанные сайты и проверяем сайты, которые пока не взломали. Работали с Joomla и 1С-Битрикс, понимаем, как устроены сайты на готовых движках и на Next.js.

Как мы работаем:

1. Диагностика. Смотрим сайт и панель хостинга, ничего не меняя. Находим вход, оцениваем масштаб и говорим, что опасно прямо сейчас.
2. Срочная остановка. Убираем то, что вредит посетителям, закрываем дыру, убираем открытые архивы, меняем пароли. Это первые сутки.
3. Полное лечение. Сверяем файлы с оригиналами, чистим базу данных, обновляем, закрываем админку. Объём зависит от сайта; в последнем случае мы закладывали от трёх до пяти рабочих дней на два сайта.
4. Наблюдение. После лечения следим за сайтом. Если в этот срок сайт заразится снова, лечим повторно бесплатно.

Цену называем после диагностики, когда понятен объём: два внешне похожих сайта могут отличаться по работе в разы. Написать нам можно через форму под статьёй или в Telegram.

Этот раздел — для того, кто будет лечить сайт сам.

Снимок до изменений

Сделайте архив файлов и дамп базы до любых правок. Даты изменения файлов (mtime) взломщик может подделать, время изменения записи в файловой системе (ctime) — нет. Поэтому ищите по ctime:

find . -type f -newerct 2026-07-01 -name "*.php" — пример поиска PHP-файлов, у которых запись в файловой системе изменилась после 1 июля. Подставьте свою дату и маски *.phtml, *.phar, .htaccess, .user.ini, а для Joomla с Helix3 — ещё и *.json.

Где искать в базе

У Joomla код шаблона хранится в #__template_styles, поле params: ключи custom_js, custom_css, before_head, before_body. Ищите по базе строки <script, eval(, atob(, base64, document.title, innerHTML, z-index:2147483647 и подписи групп вроде hacked by. У WordPress аналогичные места — wp_options и wp_posts, у 1С-Битрикс — настройки модулей, агенты и шаблоны сайта. Новые администраторы: группа 1 в Битриксе, #__users с группой Super Users в Joomla, роль administrator в WordPress.

Проверка версии PHP

Версию PHP у сайта проверяют из веба, а не командой php -v: в панелях хостинга версия выбирается для каждого сайта отдельно. Для PHP2Shell (CVE-2026-109618 и CVE-2026-109619) исправлены версии 8.5.12, 8.4.27, 8.3.36 и 8.2.35 по бюллетеню PHP от 21 октября. Для 8.1 и старше официальных выпусков нет: команда PHP опубликовала для 7.4, 8.0 и 8.1 только исправления исходного кода, которые нужно собирать самостоятельно.

Перекрыть вход до лечения

Если уязвимость известна, её адрес закрывают на уровне веб-сервера ещё до лечения. Для Helix3 это запросы option=com_ajax с plugin=helix3 от неавторизованных посетителей. Файлы, которые оставили взломщики, удаляйте только после снимка, иначе вы потеряете хронологию.

После лечения

Сравните файлы движка и расширений с официальными дистрибутивами тех же версий, обновите уязвимое, смените все пароли и ключи ($secret в configuration.php у Joomla), проверьте планировщик задач и ключи SSH. Наблюдайте за новыми файлами и изменениями настроек шаблона хотя бы 30 дней.