Взломали сайт компании: первые действия, восстановление и проверка защиты

Назначьте координатора и зафиксируйте признаки инцидента

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

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

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

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

Ограничьте доступ к опасному содержимому

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

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

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

Текст для клиентов должен отражать известное состояние. Можно сообщить о временной недоступности и рабочем канале связи. Не объявляйте отсутствие утечки, полное восстановление или точную причину до подтверждения специалистами. Внешние сообщения согласует назначенный ответственный, чтобы компания не давала противоречивых объяснений.

Сохраните данные для разбора до очистки

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

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

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

Подход к фиксации, реагированию и восстановлению рассматривается в рекомендациях NIST по управлению инцидентами. Для небольшой компании практическое применение — заранее определить ответственных и сохранять доказательства решений, не пытаясь заменить полноценный технический разбор набором скриншотов.

Уточните масштаб: сайт может быть только видимой частью

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

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

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

Восстановите контроль над доступами согласованно

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

Согласуйте порядок изменений, чтобы не потерять управление и не остановить нужные интеграции незаметно. Например, замена ключа соединения требует обновить его в принимающей системе и проверить обмен. Значения секретов не записываются в общий журнал; там достаточно факта замены, времени, владельца и результата проверки.

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

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

Выберите основу восстановления и устраните причину

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

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

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

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

Принимайте восстановление по техническим и рабочим критериям

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

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

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

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

Предупреждения поисковиков снимаются отдельным процессом

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

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

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

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

Завершите разбор планом, который можно поддерживать

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

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

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

Если признаки взлома обнаружены сейчас, подготовьте безопасное описание симптомов, время и сведения о хостинге, не включая пароли. Через контакты ШТАБ ИТ можно обсудить техническое восстановление и состав необходимых специалистов. Первое решение — кто координирует работу и как ограничивается воздействие на посетителей; дальнейшие действия принимаются по подтверждённым данным.