Pingveraблог ← Блог
Главная › Блог › Сайт взломан: что делать владельцу интернет-магазина в первые 24 часа

Сайт взломан: что делать владельцу интернет-магазина в первые 24 часа

13 октября 2026 · 12 мин чтения

Сайт взломан: что делать владельцу интернет-магазина в первые 24 часа

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

Параллельно идут два внешних трека. Первый: поисковики и браузеры, которые могли уже пометить сайт опасным. Второй: персональные данные покупателей. Если злоумышленник мог получить к ним доступ, по 152-ФЗ у оператора есть 24 часа на первичное уведомление Роскомнадзора. Ниже пошаговый план, таблица ответственности и шаблон журнала инцидента.

Коротко

  • Признаки взлома: редиректы на чужие сайты (часто только для мобильных или посетителей из поиска), новые администраторы, незнакомые cron-задачи, изменённый .htaccess, жалобы покупателей на антивирус.
  • Порядок действий: зафиксировать симптомы и время → снять копию файлов и базы → сменить все доступы → найти точку входа → вычистить и обновить → сменить пароли ещё раз.
  • Бэкап «до взлома» не спасает, если уязвимость осталась: сайт взломают снова тем же путём.
  • Если могли утечь данные покупателей, первичное уведомление в Роскомнадзор подаётся в течение 24 часов, результаты расследования в течение 72 часов.
  • После чистки запросите перепроверку в Яндекс Вебмастере. По справке Яндекса проверка идёт до 30 дней, поэтому тянуть с ней перед распродажами нельзя.

Почему это важно сейчас

До 11.11 меньше месяца, дальше «Чёрная пятница» и новогодний сезон. Взлом в это время бьёт по выручке дважды: часть трафика уходит на чужие сайты, а пометка «опасный сайт» в поиске может провисеть недели.

Поток уязвимостей в популярных платформах не останавливается. Несколько примеров, которые касаются российских магазинов:

  • 1С-Битрикс, сторонние модули. В базе уязвимостей ФСТЭК есть запись BDU:2026-08076: в модуле «Универсальный импорт» ООО «Акрит» отсутствует аутентификация для критичной функции, оценка CVSS 8.6, атака возможна по сети без учётных данных. Модули импорта и обмена ставят почти на каждый магазин, а обновляют их реже ядра.
  • 1С-Битрикс, старые дыры. В октябре 2025 года CyberOK сообщил, что около 150 тысяч из примерно миллиона активных установок 1С-Битрикс остаются уязвимы к BDU:2023-05857 в модуле landing (CVSS 10.0), хотя исправление вышло ещё в сентябре 2023 года в версии 23.850.0.
  • WordPress. Летом 2026 года волна уязвимостей в ядре и плагинах привела к массовым взломам. Мы разбирали её отдельно в статье «Массовый взлом WordPress летом 2026».

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

Пошаговый план на первые сутки

Шаг 1. Зафиксируйте симптомы (15 минут)

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

  • что именно вы видите и почему считаете, что сайт взломан;
  • когда это заметили (дата, время, часовой пояс);
  • что менялось на сайте в последние дни: новые модули или плагины, обновления, правки шаблона, новые подрядчики с доступом.

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

Шаг 2. Снимите копию текущего состояния (30–60 минут)

До любых изменений сохраните полную копию файлов и дамп базы данных, даже заражённые. В документации WordPress это прямо рекомендовано: если чистка пойдёт не так, у вас останется исходная картина для сравнения. Попросите у хостинга журналы веб-сервера за последние 2–4 недели, пока их не перезаписала ротация.

Отдельно выгрузите заказы за последние дни. Если придётся восстанавливаться из бэкапа, эти заказы нужно будет перенести вручную.

Шаг 3. Закройте все доступы (1 час)

Сменить пароль администратора недостаточно. Меняйте всё, через что можно зайти:

  • SFTP/SSH и панель хостинга;
  • пользователь и пароль базы данных (и обновите их в конфигурации сайта);
  • все учётные записи администраторов CMS, включая подрядчиков;
  • API-ключи платёжного шлюза, службы доставки, обмена с 1С, если они хранятся на сервере.

Удалите администраторов, которых вы не создавали. Для WordPress документация советует заменить секретные ключи в wp-config.php: это выбросит из админки всех, кто сейчас залогинен. В 1С-Битрикс ограничьте доступ к /bitrix/admin/ по IP, если есть такая возможность: именно это советуют исследователи для уязвимостей административных точек входа.

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

Шаг 4. Свяжитесь с хостингом

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

Шаг 5. Найдите точку входа и вычистите код (от нескольких часов)

Типичные места заражения:

  • .htaccess в корне и во вложенных папках (редиректы на казино, фишинг, чужие магазины);
  • index.php, шаблоны шапки и подвала: их код выполняется на каждой странице;
  • для 1С-Битрикс: PHP-файлы в /upload/ и /bitrix/admin/, которых нет в дистрибутиве, незнакомые папки в корне, новые задания cron;
  • для WordPress: файлы в wp-content/uploads, плагины, которых вы не ставили.

Файлы ядра безопаснее заменить целиком, чем лечить построчно. Документация WordPress советует перезалить /wp-admin и /wp-includes той же версии через SFTP, а не через кнопку переустановки в админке: установщик перезаписывает известные файлы, но не удаляет новые, подброшенные злоумышленником. Для 1С-Битрикс сравните файлы с дистрибутивом той же версии и проверьте, включён ли проактивный фильтр модуля безопасности: его часто отключают из-за ложных срабатываний и забывают включить.

Затем обновите ядро, все модули, плагины и шаблон. Удалите то, что не используете. Сторонние модули обмена и импорта проверьте по базе уязвимостей ФСТЭК (bdu.fstec.ru) и по новостям разработчика.

Шаг 6. Смените пароли ещё раз

Пароли, сменённые в шаге 3, могли быть перехвачены, пока на сайте оставался вредоносный код. После чистки смените их повторно. Документация WordPress выделяет этот шаг отдельно.

Шаг 7. Внешние треки: поиск и персональные данные

Яндекс. Откройте Вебмастер: «Оптимизация сайта» → «Безопасность и нарушения». Если там есть нарушение, после чистки опишите исправления, отметьте «Нарушение исправлено» и нажмите «Отправить на проверку». В справке срок проверки указан как «в течение 30 дней», а повторно отправить заявку можно не раньше чем через 30 дней. Поэтому отправляйте её только после полной чистки. Как проверять метку в браузерах, подробно разобрано в статье «Браузер помечает сайт опасным».

Персональные данные. Если у злоумышленника был доступ к базе с заказами, имена, телефоны и адреса покупателей могли утечь. Часть 3.1 статьи 21 152-ФЗ обязывает оператора уведомить Роскомнадзор: в течение 24 часов о произошедшем инциденте и его предполагаемых причинах, в течение 72 часов о результатах внутреннего расследования. По данным 1С:ИТС, за неуведомление организации грозит штраф от 1 до 3 млн рублей (ст. 13.11 КоАП, редакция с 30 мая 2025 года). Это не юридическая консультация: решение о том, был ли инцидент с ПДн, примите вместе с юристом, но в пределах суток.

Кто за что отвечает

Риск Ответственный Как проверить Когда
Редирект посетителей на чужой сайт Подрядчик или студия на поддержке Открыть сайт с телефона через мобильный интернет и из выдачи Яндекса В день взлома, затем ежедневно неделю
Повторный вход злоумышленника Владелец + подрядчик Список администраторов CMS, пользователи SFTP, задания cron После чистки и через 7 дней
Пометка «опасный сайт» в поиске Владелец (доступ к Вебмастеру) Раздел «Безопасность и нарушения» Ежедневно до снятия
Утечка данных покупателей Владелец + юрист Был ли доступ к базе заказов, журналы веб-сервера В первые 24 часа
Письма о заказах не доходят Подрядчик + хостинг Тестовый заказ, проверка IP в чёрных списках В день взлома
Уязвимый модуль остался на сайте Подрядчик Версии модулей и плагинов против базы уязвимостей После чистки, затем ежемесячно

Шаблон журнала инцидента

Скопируйте и заполняйте по ходу работы. Журнал пригодится и для уведомления Роскомнадзора, и для разговора с хостингом, и для разбора после инцидента.

ЖУРНАЛ ИНЦИДЕНТА: взлом сайта
Сайт: ______________________   Платформа и версия: ______________
Кто ведёт журнал: ______________

1. Обнаружение
   Дата и время (часовой пояс): ____________
   Кто и как заметил: ____________
   Симптомы (что видно, кому, с каких устройств): ____________
   Скриншоты сохранены: да / нет, где: ____________

2. Сохранение следов
   [ ] Копия файлов снята, где лежит: ____________
   [ ] Дамп базы снят, где лежит: ____________
   [ ] Журналы веб-сервера за ___ дней запрошены у хостинга
   [ ] Заказы за последние ___ дней выгружены

3. Доступы (отметить время смены)
   [ ] SFTP/SSH ______   [ ] Панель хостинга ______
   [ ] Пароль БД ______  [ ] Админы CMS ______
   [ ] Ключи платёжки, доставки, 1С ______
   Удалённые неизвестные учётные записи: ____________

4. Точка входа
   Подозреваемый компонент и версия: ____________
   Найденные вредоносные файлы и изменения: ____________

5. Чистка и обновление
   [ ] Ядро заменено файлами той же версии
   [ ] Модули, плагины, шаблон обновлены; лишние удалены
   [ ] .htaccess и cron проверены
   [ ] Пароли сменены повторно после чистки

6. Внешние треки
   [ ] Яндекс Вебмастер: нарушение есть / нет; перепроверка отправлена ______
   [ ] Доступ к ПДн покупателей: был / не было / неизвестно
   [ ] Уведомление РКН (24 ч) отправлено ______
   [ ] Результаты расследования (72 ч) отправлены ______

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

Пример разбора

Ситуация условная, собрана для иллюстрации.

Магазин бытовой техники на 1С-Битрикс. Во вторник менеджер замечает, что заказов с мобильных за два дня почти нет, а с компьютеров они идут как обычно. Владелец открывает сайт у себя на ноутбуке: всё в порядке. Менеджер открывает его с телефона из выдачи Яндекса и попадает на страницу онлайн-казино.

Студия на поддержке снимает копию файлов и базы и только потом начинает разбор. В корневом .htaccess находится правило, которое перенаправляет мобильных посетителей, пришедших из поисковиков. В /upload/ лежит PHP-файл, которого нет в дистрибутиве. Журналы показывают обращения к модулю импорта, который не обновлялся полтора года. Студия меняет все доступы, удаляет файл, восстанавливает .htaccess, обновляет модуль импорта и ядро, повторно меняет пароли. Модуль импорта имел доступ только к каталогу, но юрист магазина отдельно проверяет журналы обращений к таблицам заказов, чтобы решить вопрос с уведомлением РКН в пределах суток.

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

Частые ошибки

  • Откат на бэкап без поиска причины. Сайт снова чистый, но уязвимый модуль на месте, и через неделю всё повторяется. Заодно теряются заказы, оформленные после даты бэкапа.
  • Удаление файлов до копии. Без копии потом не понять, как злоумышленник вошёл и были ли у него данные покупателей.
  • Смена только пароля администратора. Доступ через SFTP, базу данных или ключ API остаётся открытым.
  • Проверка сайта только со своего компьютера. Подмена часто срабатывает лишь для мобильных или для переходов из поиска.
  • Отправка заявки в Вебмастер до полной чистки. Если ограничение не снимут, следующую заявку можно подать только через 30 дней.
  • Откладывание вопроса о ПДн «до выяснения». Срок 24 часа идёт с момента обнаружения, а не с момента, когда расследование закончено.

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

Вопросы и ответы

Как понять, что сайт взломан, если он открывается нормально?

Проверьте его с телефона через мобильный интернет и переходом из выдачи Яндекса, посмотрите раздел «Безопасность и нарушения» в Вебмастере, список администраторов CMS и задания cron. Резкое падение заказов с одного типа устройств или из одного канала тоже повод искать подмену.

Можно ли просто восстановить сайт из резервной копии?

Можно как часть плана, но только после того, как найдена и закрыта точка входа, а свежие заказы выгружены. Перед этим стоит убедиться, что бэкап сам по себе рабочий: как это проверить, описано в статье «Как проверить восстановление сайта из бэкапа».

Нужно ли сообщать покупателям о взломе?

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

Как не узнать о взломе от покупателей

Шаги 1 и 7 из плана выше можно не делать вручную каждый день. Pingvera проверяет сайт снаружи раз в минуту, в том числе из разных регионов и с мобильным User-Agent, и следит за неожиданными редиректами на чужие домены. Коннекторы для WordPress и 1С-Битрикс добавляют проверки изнутри, а для WooCommerce детектор аномалий сравнивает поток заказов с почасовой нормой и сообщает, если сайт работает, а заказов нет. Бесплатный тариф покрывает до 5 сайтов.

Источники

  • FAQ My site was hacked — документация WordPress.org
  • Яндекс Вебмастер: безопасность и нарушения, перепроверка сайта
  • 152-ФЗ «О персональных данных», статья 21 — КонсультантПлюс
  • 1С:ИТС — уведомление Роскомнадзора об утечке персональных данных
  • BDU:2026-08076 — модуль «Универсальный импорт» ООО «Акрит»
  • Anti-Malware: около 150 тыс. сайтов на 1С-Битрикс уязвимы к BDU:2023-05857
  • Хабр: 10 ошибок безопасности Bitrix без новых CVE (июнь 2026)
  • Workspace: признаки взлома сайтов на шаблонах Аспро

Проверено: 13 октября 2026 года

Узнавайте о проблеме раньше клиента

Pingvera следит за сайтами клиентов «снаружи и изнутри» — доступность из регионов, формы, оплата, домен, SSL, сервер — и предупреждает в Telegram, email и Max раньше, чем напишет клиент.

Попробовать Pingvera бесплатно

Читайте также: Метка «опасный сайт» в браузере: что делать · Не проходит оплата на сайте: что проверить магазину · Перехватывают клиентов с сайта: как узнать и что делать · Что делать, если сайт клиента упал: регламент · Проверить WordPress-сайт.

← Все статьи · Политика конфиденциальности · pingvera.ru · Telegram-канал

На сайте осуществляется обработка пользовательских данных с использованием Cookie в соответствии с Политикой конфиденциальности.