
Редакция Romanov Lab · Опубликовано
Подозрительный скрипт, неизвестный администратор или перенаправление посетителей требуют двух параллельных действий: ограничить возможный вред и сохранить сведения для расследования. Простое удаление видимого файла может убрать симптом и одновременно уничтожить часть следов. Восстановление должно отвечать на вопросы, как произошло проникновение, что затронуто и почему прежний путь больше не работает.
Зафиксируйте признаки без поспешного вывода
Запишите, кто и где заметил проблему, какие страницы затронуты, какое время показывают источники и есть ли идентификаторы событий. Сохраните безопасные снимки видимого поведения и исходные технические сообщения. Не открывайте подозрительное вложение и не запускайте найденный скрипт ради проверки его назначения.
Отличайте подтверждённый факт от версии. Неизвестный файл может быть следствием легитимного обновления, но появление нового привилегированного пользователя требует срочной проверки. Отсутствие предупреждения антивируса не подтверждает целостность сайта, а исчезновение симптома не означает завершения инцидента.
Назначьте ответственного за технические действия и отдельного человека, принимающего решения о доступности сервиса и сообщениях клиентам. Общая координация описывается в регламенте инцидентов; здесь важны доказательства компрометации и критерии безопасного возвращения.
Ограничьте последствия через доверенный канал
Работайте с проверенного устройства и через административный канал, который не считается скомпрометированным. Если сайт раздаёт вредоносный код или раскрывает данные, ответственному может потребоваться ограничить доступ к затронутой части либо изолировать площадку. Вид ограничения выбирают с хостингом или специалистом, учитывая сохранение данных и других сервисов на том же сервере.
Не вносите новые секреты через подозрительную административную панель. Не отключайте защиту хостинга ради доступа к заражённому экземпляру. При продолжающейся утечке или разрушении приоритет получает сдерживание, а порядок сохранения свидетельств согласуют со специалистом настолько быстро, насколько позволяет ситуация.
Руководство CISA по реагированию на ransomware рассматривает изоляцию и сохранение быстро исчезающих свидетельств. Эти принципы полезны и при расследовании компрометации сайта, но не означают, что любой неизвестный файл связан с шифровальщиком. Конкретные действия определяют по установленному инциденту.
Сохраните материалы до очистки
С хостингом или специалистом определите доступные снимки диска, копии изменённых файлов, журналов приложения и веб-сервера, событий входа, изменений пользователей и DNS. Для серьёзного инцидента может потребоваться сохранение оперативной памяти и других нестойких данных; неподготовленному владельцу не стоит экспериментировать на рабочем сервере.
Для каждой копии отметьте источник, время получения с часовым поясом, исполнителя и способ проверки целостности. Храните оригинал отдельно от рабочей копии анализа, ограничьте доступ. Контрольная сумма подтверждает неизменность относительно сохранённого экземпляра, но сама по себе не доказывает, что исходный файл был безопасен.
Запросите сохранение нужного периода у провайдера до его обычного удаления. Не загружайте полный архив сайта или базу в публичный сервис сканирования: внутри могут находиться ключи и персональные данные. Передача стороннему специалисту требует согласованного объёма и защищённого канала.
Постройте временную последовательность
Начните с первого подтверждённого признака и двигайтесь назад по доступным событиям. Сопоставьте входы, создание учётных записей, изменение файлов, установку расширений, выполнение заданий и исходящие соединения. Уточните, какие часы использует каждый источник и нет ли пробелов в истории.
Время изменения файла — лишь один признак: оно могло измениться при копировании или быть подделано. Сравните код с доверенным выпуском и официальными пакетами, а изменения конфигурации — с утверждённым состоянием. Нельзя объявить все отличия вредоносными: на сайте могли быть законные доработки, которые тоже надо объяснить.
Границы расследования включают не только файлы сайта. Проверьте связанные аккаунты, репозиторий, механизм выкладки, фоновые задания, хранилище и учётные данные интеграций в пределах разрешённого доступа. Если скомпрометирован административный аккаунт хостинга, проверка одной CMS слишком узкая.
Учебный разбор: неизвестный скрипт вернулся после удаления
Предположим, в шаблоне появилась посторонняя вставка. Её удалили, страница снова выглядит нормально, но позже вставка возникает вновь. Это основание искать сохранившийся механизм изменений, а не повторять очистку. Возможны разные причины: доступный злоумышленнику аккаунт, уязвимый компонент, изменённый источник выкладки или фоновое задание.
Команда сохраняет оба состояния, находит момент повторного изменения и сопоставляет его с событиями. Если выявлен несанкционированный вход и изменение из панели, проверяются сессии, созданные пользователи и действия аккаунта. Если изменение совпало с выкладкой, сравниваются доверенный репозиторий и фактически доставленный пакет. До подтверждения нельзя приписывать причину определённому человеку или компоненту.
Восстанавливайте из доверенной основы
При нарушенной целостности окружения предпочтительно собрать чистую площадку из проверенных компонентов, а нужные данные перенести после проверки. Возврат полной копии заражённого сервера способен вернуть тот же механизм повторного доступа. Даже архив, созданный раньше обнаружения, мог уже содержать компрометацию.
Выберите точку восстановления по свидетельствам, проверьте её в изоляции и устраните подтверждённый путь проникновения. Обновление уязвимого компонента, закрытие лишнего доступа и замена затронутого секрета решают разные части задачи. Одного обновления CMS недостаточно, если злоумышленник сохранил иной доступ.
Секреты, которые могли быть раскрыты, отзывают и заменяют из доверенной среды с учётом зависимостей. Область ротации определяется тем, к чему был доступ: база, почтовый транспорт, внешние API, хранилище или выкладка. Одновременно проверяют отдельные токены и активные сессии; изменение одного пароля не доказывает их прекращение.
Проверьте безопасность и бизнес-данные отдельно
- Подтверждённая причина устранена, прежний путь доступа закрыт и проверен безопасным способом.
- Файлы и конфигурация соответствуют доверенной основе, оставшиеся отличия объяснены.
- Учётные записи, ключи и расписания имеют известное назначение и владельца.
- Восстановленные заявки, заказы и загрузки согласованы; изменения после выбранной копии разобраны.
- На контролируемых тестах работают формы, авторизация и необходимые интеграции.
- После возвращения трафика наблюдение способно заметить повторные признаки и достигает ответственного.
Функциональные проверки дополняют испытание восстановления из копии, но не заменяют расследование. Работающая корзина ничего не говорит о неизвестном токене администратора.
Зафиксируйте пределы установленных фактов
Отчёт должен разделять подтверждённый доступ, обнаруженные изменения, возможные последствия и то, что проверить не удалось. Фраза «данные не утекли» требует доказательств; отсутствие записей в неполном журнале их не даёт. Вопросы уведомления клиентов, партнёров и уполномоченных органов передают ответственным за правовые обязанности с учётом конкретных данных и юрисдикции.
NIST SP 800-61 Rev. 3 рассматривает реагирование вместе с управлением рисками и улучшением защиты. Практический итог для сайта — исправленная причина, проверенное восстановление, понятные ограничения расследования и назначенные действия, которые уменьшают вероятность повторения.
Нужен план для вашего проекта? Напишите нам в Telegram или по электронной почте. Обсудим разработку, продвижение или поддержку сайта.


