Сайт взломали: аварийный план для владельца сайта на WordPress и 1С-Битрикс

Собственник производственной компании, звонок в среду утром: «Клиент написал, что наш сайт с телефона перекидывает на казино. Открываю с ноутбука — всё в порядке. Через час письмо от хостинга: с нашего аккаунта идёт спам, дали сутки. Маркетолог поставил заглушку „Сайт на обслуживании“ — а хостинг пишет, что рассылка продолжается».

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

Дальше — порядок действий, который не уничтожает то, что понадобится для разбора: для сайта на WordPress или 1С-Битрикс и для руководителя без своего ИТ-отдела. Команды вынесены в отдельный блок: их выполняет ИТ-специалист, а не директор.

Коротко. Ограничьте воздействие на стороне хостинга — остановите исполнение кода и отправку почты, а не просто замените главную страницу. До любых правок снимите копию заражённого состояния вместе с журналами. Найдите точку входа. Смените доступы, начиная с панели хостинга и управления DNS. Восстановитесь из проверенной копии, одновременно закрыв уязвимость, и только потом запрашивайте перепроверку у поисковых систем. Чистый результат онлайн-сканера и заглушка не означают, что инцидент закрыт.

Как отличить взлом от обычного сбоя

Версия «просто что-то сломалось» перестаёт работать, когда есть один из признаков:

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

Что действительно указывает на компрометацию: изменённые файлы ядра CMS относительно эталона; неизвестные файлы с обфусцированным кодом; посторонние задания в планировщике; администраторы, которых нет в вашем списке; неизвестные ключи в ~/.ssh/authorized_keys; разное поведение сайта для поискового робота и для посетителя.

Что само по себе ни о чём не говорит. Обычные PHP-файлы в каталоге /local/ у 1С-Битрикс — не признак заражения: это штатное место для пользовательских компонентов и обработчиков, туда кладёт код любой нормальный разработчик. Не приговор и единичное срабатывание сканера на минифицированном JavaScript. Подозрительная находка — повод разобраться, а не команда на удаление.

Проверьте и то, о чём предупреждает браузер: «подключение не защищено» из-за истёкшего или отозванного сертификата к взлому отношения не имеет — это отдельная история. А если зашифрованы файлы и требуют выкуп, речь о шифровальщике, и порядок действий там свой.

Что владелец может проверить сам

Три вещи можно сделать без доступа к серверу. Все три — фиксация, не диагноз.

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

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

Первые часы: что сделать и чего не делать

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

Ограничить доступ своими силами можно, но осторожно: на Apache 2.4 это директива Require ip 203.0.113.10 (адрес свой), устаревшие Order deny,allow работают не везде, а nginx .htaccess не читает вовсе. Убедитесь также, что перед сайтом нет CDN или прокси.

Ответить хостингу. Письмо в тикет: уведомление получено, доступ ограничен, копия снята, работы ведём. Там же просите отчёт сканера, журналы доступа за месяц и список заданий планировщика. Условия блокировки устанавливает хостинг, и письмо их не отменяет — но молчание блокировку ускоряет.

Чего не делать. Не удалять подозрительные файлы поодиночке: так уничтожаются следы и теряется точка входа. Не откатываться на последнюю копию рефлекторно. Не менять версию PHP посреди разбора. Не запускать «универсальные команды лечения» из интернета: массовая замена по шаблону чаще ломает рабочий код, чем убирает вредоносный.

Сохранить состояние до того, как что-то менять

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

В копию входят файлы сайта, дамп базы, журналы доступа и ошибок веб-сервера, журнал почты, задания планировщика, список пользователей CMS и хостинга, конфигурация. Отдельно зафиксируйте время: когда появились первые признаки, когда снята копия и кем. Хранить архив нужно вне публичного каталога и с ограниченными правами — архив с базой клиентов, доступный по прямой ссылке, превращает один инцидент в два. Состав фиксации под возможные претензии определяет специалист.

Локализация: где искать и что считать признаком

WordPress. Смотрят на исполняемые файлы среди пользовательских загрузок, изменения в корневых файлах и .htaccess, каталог обязательных плагинов, автозагружаемые записи в настройках, задания планировщика, плагины и темы, снятые с поддержки. Проверка контрольных сумм сравнивает ядро и плагины из официального каталога с эталоном, но не покрывает коммерческие и самописные компоненты, базу и способы закрепления: успешная проверка не равна «сайт чист».

1С-Битрикс. Первым делом — встроенные инструменты: «Настройки → Проактивная защита → Панель безопасности», контроль целостности файлов, журнал вторжений. Контроль целостности показывает отличия от эталонного пакета, и это список для разбора, а не список на удаление: в него попадают и легальные доработки, и остатки обновлений. По каждому отличию устанавливают происхождение и содержимое. Массовые взломы Битрикс-сайтов в 2022–2025 годах шли через известные уязвимости, патчи к которым уже вышли; в мае 2023 года бюллетень по этому поводу выпускал НКЦКИ.

Для ИТ-специалиста: команды, которые только читают

Эти команды ничего не изменяют. Их результат — список для проверки, не приговор файлу.

# исполняемый код среди загрузок пользователей (WordPress)
find wp-content/uploads -type f -name "*.php"

# что менялось за неделю, кроме кеша
find . -type f -mtime -7 -not -path "./wp-content/cache/*" | head -200

# сигнатуры обфускации: сигнал к проверке, не доказательство
grep -rlE "eval\(|base64_decode\(|gzinflate\(|str_rot13\(" . | head -50

# посторонние задания планировщика и неизвестные ключи доступа
crontab -l
cat ~/.ssh/authorized_keys

# разное поведение для робота и для посетителя
curl -sI https://site.ru/
curl -sI -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" -e "https://yandex.ru/" https://site.ru/

Проверку контрольных сумм ядра и плагинов WordPress выполняют с указанием версии и локали; такие команды загружают код сайта, поэтому в заражённой среде их лучше запускать на копии. Для 1С-Битрикс сверку делают штатным контролем целостности, а различия разбирают с разработчиком.

Персональные данные: отдельный шаг с жёстким сроком

Если через сайт собирались заявки или заказы, взлом может означать инцидент с персональными данными, и это уже не техническая задача.

При установленном факте неправомерного или случайного доступа к персональным данным, повлёкшем нарушение прав субъектов, оператор уведомляет Роскомнадзор в течение 24 часов с момента выявления инцидента, а результаты внутреннего расследования передаёт в течение 72 часов с того же момента — часть 3.1 статьи 21 152-ФЗ. Отсчёт идёт от выявления, а не от окончания лечения сайта.

Практический вывод: при признаках взлома сайта с формами запускайте проверку по данным параллельно с техническими работами — что в них было, куда они уходили, сохранились ли журналы отправки. Квалификацию инцидента подтверждает специалист вместе с юристом; отсутствие форм само по себе не означает, что персональных данных не было — они бывают в учётных записях, журналах и интеграциях. Что должно быть на стороне сайта — в статье «152-ФЗ для корпоративного сайта».

Пароли и ключи: порядок, который не сломает бизнес

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

1. Панель хостинга и управление DNS у регистратора — вместе с почтой восстановления и вторым фактором. Пока верхний уровень не ваш, остальное можно откатить.
2. Доступ к серверу: SSH, SFTP, FTP-пользователи, ревизия ключей в authorized_keys.
3. База данных — пароль пользователя и соответствующая запись в конфигурации сайта.
4. Админка CMS: все администраторы, удаление неизвестных учётных записей, смена ключей сессий.
5. Интеграции: CRM, платёжный шлюз, служба рассылок, ключи развёртывания, внешние сервисы форм.

Пятый пункт — тот, на котором обычно спотыкается бизнес. Смена пароля базы или SMTP-логина ломает интеграции молча: заявки не доходят, письма не отправляются, а обнаруживается это через два дня по отсутствию звонков. Поэтому список интеграций составляют заранее, а после каждого шага проверяют, что связанный процесс работает.

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

Восстановление: как выбрать точку и как её проверить

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

Критерий выбора точки восстановления — она должна быть заведомо раньше самого раннего подтверждённого признака компрометации. Признаки берут из журналов доступа, времени изменения файлов, дат появления посторонних учётных записей и заданий, первых жалоб клиентов. Возраст копии сам по себе ничего не доказывает: вчерашняя может быть чистой, а трёхмесячная — уже заражённой.

Обязательная проверка перед возвратом в работу. Копию разворачивают в изолированной среде, а не поверх рабочего сайта, и сверяют файлы с эталонной версией CMS, проверяют пользователей, задания и содержимое базы. Одновременно закрывают точку входа: обновляют уязвимый компонент, убирают заброшенные плагины и модули, отзывают лишние доступы. Возврат в онлайн без закрытой точки входа — это повторное заражение тем же способом за несколько дней.

Проверять восстановление лучше не в аварию, а по регламенту — процедура и форма протокола в статье «Тестовое восстановление из бэкапа». Компания, которая делала такой тест раз в квартал, здесь уже знает, что копия разворачивается и за сколько.

Возврат в поиск и снятие предупреждений

Этот шаг идёт только после устранения причины: запрос при оставшемся вредоносном коде отклоняется и удлиняет ожидание.

• Приведите в порядок то, что видит поисковая система: внедрённые страницы и шаблоны адресов, подменённые заголовки и описания, карту сайта, robots.txt, канонические ссылки. Проверьте и подтверждённых владельцев в панелях вебмастеров: посторонний сохраняет доступ и после лечения.
• Удалённые вредоносные страницы должны отвечать 404 или 410. Массовый редирект мусора на главную поисковая система читает как ещё одну манипуляцию.
• Запрос перепроверки отправляйте из соответствующего отчёта панели вебмастера, описав, что было и что сделано. В Google «Проблемы безопасности» и «Меры, принятые вручную» — разные отчёты, запросы по ним подаются отдельно. Сроки не гарантируются: задержка сама по себе не означает, что заражение осталось.
• Инструмент временного удаления адресов скрывает страницы из выдачи, но не чистит сайт: это мера на время работ, а не результат.

После запуска проверьте живые сценарии: отправку форм, доставку писем, передачу заявок в CRM, оплату, поведение сайта с мобильного и из поиска.

Кто что делает

Инцидент разваливается там, где владелец ждёт хостинг, хостинг — ИТ-подрядчика, а тот — решения владельца. Роли разводят с первого часа.

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

Почему это случилось и что закрывать

Причину устанавливают по журналам, версиям компонентов и способам доступа, а не по общим правилам. Но набор факторов в заявках повторяется.

Компоненты, которые давно не обновляли. Отчёт Patchstack «State of WordPress Security in 2026» по данным 2025 года фиксирует 11 334 новые уязвимости в экосистеме WordPress, 91 % из них — в плагинах, и отмечает, что 46 % не имели исправления на момент публичного раскрытия.

Закрытый канал обновлений. У 1С-Битрикс без действующей лицензии сайт работает, но обновления безопасности не приходят. Сюда же устаревший PHP: ветка 8.1 без исправлений безопасности с 31 декабря 2025 года, 8.2 — до 31 декабря 2026 года, а 1С-Битрикс с 1 февраля 2026 года не поддерживает PHP ниже 8.2. Сайт на старой ветке не обновить без миграции, а миграцию нельзя делать вслепую посреди аварии.

Организационные дыры. Доступы на аккаунтах бывшего ИТ-подрядчика; резервная копия только у хостинга и внутри того же аккаунта; забытые копии на поддоменах test. и old. с реальной базой; администраторы, которых не сверяли со списком сотрудников.

Регламент, который это закрывает, простой: обновления по расписанию с проверкой на копии, ежедневная копия во внешнее хранилище, независимое от хостинга, ежеквартальный тест восстановления, ревизия доступов, контроль сроков лицензии, домена и сертификата. Как это встраивается в общую защиту компании — в статье «Кибербезопасность для бизнеса». Отдельная ИТ-поддержка для сайта не нужна: корпоративный сайт — часть ИТ-инфраструктуры и обслуживается в общем контуре ИТ-аутсорсинга.

Что дальше

Если признаки взлома уже есть, начните с двух вещей: ограничьте исполнение кода и отправку почты на стороне хостинга и снимите копию состояния с журналами.

Визард-АйТи проводит первичную оценку инцидента и согласует план восстановления. Результат работ — отчёт: причина и точка входа, что изменено, какие проверки выполнены, что осталось за их пределами. Сроки называем после диагностики, а не до неё.

Читайте также:

• Тестовое восстановление из бэкапа
• Кому принадлежат домен, почта и сайт компании
• 152-ФЗ для корпоративного сайта
• Реестр ИТ-активов компании: шаблон

Источники

Все ссылки проверены 5 сентября 2026 года.

• Федеральный закон от 27.07.2006 № 152-ФЗ, часть 3.1 статьи 21 — сроки уведомления Роскомнадзора: 24 и 72 часа.
• Patchstack, «State of WordPress Security in 2026» (данные 2025 года): patchstack.com/whitepaper/state-of-wordpress-security-in-2026/
• PHP, поддерживаемые и завершившие поддержку ветки — php.net/supported-versions.php, php.net/eol.php
• 1С-Битрикс, требования к окружению и структура каталогов (назначение /local/): dev.1c-bitrix.ru, docs.1c-bitrix.ru
• НКЦКИ, бюллетень об угрозе заражения сайтов под управлением 1С-Битрикс (май 2023): cert.gov.ru
• Apache HTTP Server 2.4, управление доступом (Require) — httpd.apache.org/docs/2.4/howto/access.html

Мы не юристы: квалификацию инцидента с персональными данными подтверждайте с юристом.