Сайт компании взломали и подменили содержимое: план действий

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

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

Особенности дефейса

Взлом сайта это всегда следствие. Признак того, что злоумышленник уже получил доступ к инфраструктуре организации. Но пока вы смотрите на испорченную главную страницу, он уже мог:

• оставить бэкдор (скрытый доступ в систему для возврата) для будущих визитов;
• установить веб-шелл (вредоносный скрипт на сервере для удалённого управления через браузер) для удалённого управления;
• заразить сайт вредоносным кодом, который теперь атакует посетителей;
• похитить базу клиентов или внедрить SEO-отраву, обрушивающую позиции в поисковой выдаче.

От взлома веб-ресурса и внедрения бэкдора до непосредственно дефейса может пройти несколько месяцев. Злоумышленник мог находиться в системе полгода, а вы даже не подозревали. И вот теперь он решил проявить себя.

В 2025 году акцент злоумышленников, атакующих российские компании, сместился с дефейсов, хищения данных и DDoS-атак на полное уничтожение инфраструктуры. 76% критических кибератак были направлены на уничтожение инфраструктуры. Специалисты зафиксировали серию атак, где злоумышленники использовали взломанные сайты для распространения вредоносного IIS-модуля BadIIS, превращая легитимные ресурсы в рассадник заразы.

В третьем квартале 2025 года индивидуальные предприниматели оказались самой уязвимой категорией для дефейс-атак. За первые два месяца лета 2025 года дефейс-атаки затронули 34% индивидуальных предпринимателей и 36% микропредприятий.

Первые 60 минут

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

Шаг 1. Фиксация и изоляция

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

1. Создать полный дамп — скопируйте все файлы сайта, базу данных, логи веб-сервера, логи доступа, конфигурационные файлы. Всё, что находится на сервере и в сопутствующей инфраструктуре.
2. Зафиксировать подменённый контент — сделайте скриншоты и видеозапись с разных устройств и из разных браузеров. После восстановления доказать факт подмены будет значительно сложнее.
3. Зафиксировать точное время обнаружения инцидента — оно потребуется для отчётности и юридических процедур.
4. Отключить сайт от интернета — переведите в режим обслуживания или замените на статическую заглушку «сайт на технических работах». Это предотвратит дальнейшие действия злоумышленника и остановит распространение вредоносного кода на посетителей.

Шаг 2. Оповещение команды и руководства

Расследование дефейса является командной работой, поэтому важно ввести всех причастных в курс дела:

1. Уведомить CISO и CEO об инциденте и начале работы по нему.
2. Сформировать группу реагирования на инциденты с распределением ответственности за анализ, техническое устранение и коммуникации.
3. Определить роли: технический анализ, юридическое сопровождение, взаимодействие с клиентами и PR.

Шаг 3. Изоляция инфраструктуры

Отключение атакованного сайта — это только первый этап. Необходимо проверить:

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

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

Расследование

После локализации угрозы (сайт отключён, риск распространения минимизирован) начинается этап расследования.

Шаг 4. Анализ журналов регистрации

Основные источники данных для анализа:

• журналы доступа веб-сервера (access_log, error_log) — фиксация источников и времени обращений;
• журналы CMS и плагинов — особенно для систем WordPress, Joomla, DNN;
• журналы FTP/SFTP — выявление фактов загрузки подозрительных файлов;
• журналы SSH — при получении злоумышленником доступа к серверу.

Признаками аномалий являются нехарактерное время доступа, подозрительные IP-адреса, попытки загрузки файлов с расширениями .php, .asp, .jsp, маскирующихся под системные или графические файлы (веб-шеллы).

Шаг 5. Определение точки входа

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

1. Уязвимости в CMS или плагинах — несвоевременное обновление движка сайта.
2. Скомпрометированные учётные данные — пароль от админки, полученный злоумышленниками.
3. SQL-инъекции и другие веб-уязвимости.
4. Вредоносные модули.

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

Шаг 6. Сбор доказательств для правоохранительных органов

При планировании обращения в правоохранительные органы (а при значительном ущербе это обязательно) необходимо сохранить:

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

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

Уведомление регуляторов

В Российской Федерации установлен обязательный порядок уведомления уполномоченных органов о компьютерных инцидентах. Сроки и порядок зависят от отнесения организации к субъектам критической информационной инфраструктуры.

Для субъектов КИИ

Приказом ФСБ России от 25 декабря 2025 года № 547 утверждён Порядок информирования ФСБ России о компьютерных атаках и компьютерных инцидентах, реагирования на них, принятия мер по ликвидации последствий.

Обязанности по информированию возложены на органы и организации в соответствии с частью 4 статьи 9 Федерального закона от 26 июля 2017 года № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации».

Информация направляется в НКЦКИ не позднее 48 часов после завершения мероприятий по реагированию.

Для организаций, не являющихся субъектами КИИ

Уведомление в НКЦКИ носит рекомендательный характер, однако:

• при утечке персональных данных — обязательное уведомление Роскомнадзора;
• при нарушении работы банковских сервисов — уведомление ФинЦЕРТ (Банк России).

Проведение внутреннего расследования является смягчающим обстоятельством для регуляторов при назначении штрафных санкций. Отсутствие расследования и уведомлений влечёт существенные финансовые риски. Штрафы за утечку персональных данных в 2025 году значительно возросли.

Восстановление

После завершения следственных действий и уведомления регуляторов (при необходимости) осуществляется восстановление.

Шаг 7. Удаление вредоносного кода

1. Удаление всего постороннего контента, всех файлов, добавленных или модифицированных злоумышленником.
2. Проверка наличия бэкдоров, скрытых файлов, обеспечивающих возможность повторного доступа.
3. Смена всех паролей, от админки CMS, FTP/SFTP, хостинга, базы данных.

Шаг 8. Восстановление из резервной копии

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

Шаг 9. Устранение уязвимости

На основе результатов расследования необходимо закрыть точку входа:

• обновление CMS и всех плагинов;
• исправление выявленных уязвимостей в коде;
• установка WAF;
• настройка двухфакторной аутентификации для административного доступа.

Шаг 10. Восстановление доверия поисковых систем

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

• запросить повторную проверку в поисковых системах;
• удалить вредоносные страницы из индекса.

Юридическая ответственность

Неправомерный доступ к компьютерной информации квалифицируется по статье 272 Уголовного кодекса Российской Федерации. Ответственность за дефейс сайта зависит от обстоятельств инцидента:

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

В зависимости от этих факторов наказание может варьироваться от административных штрафов до уголовной ответственности.

Правоохранительные органы также имеют возможность установить личность злоумышленника даже при использовании подложных IP-адресов. Ключевым фактором служит своевременность обращения и полнота предоставленных доказательств.

Типичные ошибки

1. Перезагрузка сервера до сохранения улик. Уничтожение доказательной базы влечет за собой прекращение расследования.
2. Отсутствие резервных копий. Восстановление без бэкапа занимает недели вместо часов.
3. Игнорирование уведомления регуляторов. Штрафные санкции могут многократно превышать затраты на восстановление.
4. Восстановление без устранения причины. Повторный взлом неизбежен.
5. Отсутствие юридического сопровождения. Неправильно оформленные доказательства не принимаются судом; некорректно поданные уведомления влекут административную ответственность.

Заключение

Взлом и подмена содержимого сайта это системный инцидент, требующий комплексного подхода:

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

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

Автор статьи: Филиппова Анастасия, специалист по информационной безопасности «Астрал. Безопасность».