В последнее время всё чаще прилетают вопросы и просьбы о консультации после самых разных инцидентов: кого‑то зашифровали, где‑то поломали инфраструктуру, где‑то увели корпоративную почту или получили доступ к учёткам.
В зрелых с точки зрения ИБ компаниях такие ситуации обычно уже разобраны в процедурах реагирования, а у команд есть понимание, кто и что делает в первые минуты и часы инцидента.
Но если с инцидентом компания сталкивается впервые. И вот там начинается самое сложное: всё лежит, бизнес нервничает, информации мало, а делать что‑то надо прямо сейчас.
В такой момент очень легко начать действовать слишком активно: перезагрузить сервер, удалить подозрительный файл, почистить логи, начать восстановление из бэкапа, и тем самым случайно усложнить дальнейший разбор ситуации.
Ниже семь базовых правил о том, что стоит сделать и чего, наоборот, лучше не делать в момент инцидента, пока ситуация ещё не локализована, не определён дальнейший план действий и не понятно, кто именно будет заниматься разбором последствий и восстановлением.
Представленные ниже правила. Для кого‑то очевидная, для кого‑то уже давно формализованная во внутренних процедурах. Но если организация столкнулась с таким впервые, эти несколько действий могут сильно повлиять на то, сколько информации удастся сохранить и насколько быстро потом получится разобраться в произошедшем.
1. Изолировать пострадавшие системы
Первое действие — отключить пострадавшие машины от сети.
LAN, Wi‑Fi, VPN. Если понятно, где проходит граница инцидента, изолируем конкретные хосты или сегмент.
Если такой границы нет, непонятно, сколько систем уже затронуто, а атака может продолжаться, иногда правильнее временно отключить всю сеть целиком, чем оставить злоумышленнику возможность дальше перемещаться по инфраструктуре.
Это неприятное решение, особенно когда бизнес уже стоит, но в первые минуты задача не сохранить доступность любой ценой, а не дать инциденту стать ещё больше.
При этом изолировать — это не значит выключить сервер. Сами системы по возможности лучше не трогать. Лучше всего изолировать систему вне самого хоста: ACL на коммутаторе, межсетевым экраном, отключением порта или физически отключив сетевой кабель. Если другого варианта нет, можно ограничить сеть и средствами самой системы (iptables/nftables, Windows Firewall и тому подобное).
Если изоляция выполняется программно, важно не ограничиваться только входящими соединениями. Исходящий трафик тоже необходимо заблокировать, иначе скомпрометированная система может продолжать общаться с инфраструктурой злоумышленника или другими узлами внутри сети.
Сначала останавливаем распространение, потом разбираемся с последствиями.
2. Не перезагружать и не выключать всё подряд
Очень частая реакция на инцидент: сервер зашифрован, перезагружаем. Не помогло, выключаем.
По возможности так делать не надо.
После перезагрузки или выключения мы теряем часть информации, которая может пригодиться при разборе инцидента: содержимое оперативной памяти, активные соединения, запущенные процессы и другие следы того, что происходило на системе в этот момент.
Поэтому, если распространение удалось остановить изоляцией, сервер лучше оставить в текущем состоянии и лишний раз не трогать.
Конечно, бывают ситуации, когда вредонос прямо сейчас продолжает шифровать данные или ломать систему и остановить это иначе невозможно. В таком случае сохранность инфраструктуры важнее идеальной криминалистики.
Но перезагрузка или выключение сервера просто «на всякий случай» — плохая идея.
Сначала сохраняем текущее состояние системы, а уже потом решаем, что с ней делать дальше.
3. Ничего не удалять и не «чистить»
Ещё одна очень понятная реакция — найти что‑то подозрительное и сразу это удалить.
Не надо.
Не запускайте очистку антивирусом, не удаляйте подозрительные файлы, не чистите%TEMP%, журналы событий и другие следы. По возможности не завершайте подозрительные процессы просто потому, что они выглядят подозрительно, если вы однозначно не понимаете, что делаете.
То, что сейчас кажется мусором, потом может оказаться важным артефактом: файлом, из которого запускался вредонос, логом с нужным временем, командной строкой процесса или следом перемещения злоумышленника по инфраструктуре.
Иногда одного такого артефакта хватает, чтобы понять, откуда началась атака и что происходило дальше.
Поэтому если система уже изолирована и дальнейший ущерб остановлен, ничего в ней лишний раз не меняем.
Сначала сохраняем и разбираемся, потом удаляем и чистим..
4. Не начинать восстановление из бэкапов
Когда всё зашифровано или сломано, первая мысль обычно простая: есть бэкап — сейчас восстановим и поедем дальше.
С этим лучше не спешить.
Сначала надо понять хотя бы две вещи: целы ли сами резервные копии и не остался ли злоумышленник внутри инфраструктуры.
Если просто восстановить сервер и вернуть его обратно в ту же среду, можно через какое‑то время получить второй раунд атаки и снова потерять уже восстановленные данные.
Отдельно стоит беречь offline‑бэкапы. Не надо подключать их напрямую к потенциально скомпрометированной инфраструктуре только ради того, чтобы «быстро проверить, что там есть».
Поэтому, если резервные копии ещё не затронуты, лучше вообще ничего с ними не делать до понимания масштаба инцидента и дальнейшего плана восстановления.
Сначала понимаем масштаб инцидента, проверяем бэкапы и определяем безопасный способ восстановления — потом восстанавливаем.
5. Закрыть очевидно скомпрометированные доступы
Если уже понятно, как злоумышленник попал внутрь — этот канал надо закрыть.
Это может быть конкретная учётная запись, VPN, открытый RDP, SSH, почтовая учётка или другой внешний доступ. Если речь идёт об учётной записи, по возможности стоит не только заблокировать её, но и завершить активные сессии/отозвать токены.
По возможности лучше делать это на периметре или с доверенной системы, а не с компьютера, который сам может быть скомпрометирован.
При этом не надо в первые минуты устраивать глобальную смену всех паролей и перестраивать половину инфраструктуры. Массовые изменения в первые минуты создают дополнительный шум, меняют состояние инфраструктуры и могут сильно усложнить дальнейший разбор.
Задача на этом этапе проще: закрыть известный канал входа и не дать злоумышленнику продолжать им пользоваться.
Сначала перекрываем очевидный доступ, потом уже спокойно разбираемся со всеми учётками, ключами, сессиями и настройками.
6. Зафиксировать, что произошло
В момент инцидента всё обычно происходит быстро, поэтому очень легко потерять простые, но потом важные детали.
Потратьте несколько минут и просто зафиксируйте факты:
когда впервые заметили проблему;
кто и что именно увидел;
какие системы точно пострадали;
какие на первый взгляд ещё работают;
что происходило непосредственно перед обнаружением;
точное время и часовой пояс;
что администраторы уже успели сделать после обнаружения.
Обо всём этом вас потом спросит любой расследователь. А если разбираться в инциденте придётся самостоятельно — эти же вопросы вы будете задавать сами себе. Через несколько часов вспомнить, кто, что и в какой последовательности делал, бывает неожиданно сложно.
Сделайте скриншоты ransom note, ошибок, подозрительных сообщений и текущего состояния систем.
Не надо сразу пытаться строить полноценный таймлайн атаки или делать выводы о том, как именно злоумышленник попал внутрь. На этом этапе гораздо важнее записать то, что известно наверняка, пока это ещё никто не забыл.
Сначала фиксируем факты и свои действия, потом уже восстанавливаем полную картину произошедшего.
7. Остановиться
Наверное, самое сложное правило — вовремя перестать что‑то делать.
Если заражённые системы уже изолированы, очевидные каналы доступа закрыты, текущее состояние зафиксировано, а дальнейшее распространение остановлено — не надо продолжать экспериментировать просто потому, что хочется что‑то ещё проверить или починить.
Не надо ставить несколько антивирусов подряд, удалять всё подозрительное, переустанавливать контроллер домена, возвращать серверы в production или пытаться на ходу «найти хакера».
С этого момента начинается уже другая работа: сбор артефактов, поиск точки входа, восстановление последовательности событий, проверка перемещений по сети, persistence и оценка реального масштаба компрометации.
Этим может заниматься отдельный расследователь, внутренняя ИБ‑команда или те же администраторы, если разбирать инцидент придётся своими силами. Но в любом случае это уже должно быть осознанное расследование по плану, а не набор случайных действий.
Cначала остановили инцидент и сохранили следы, потом разбираемся, что произошло и как восстанавливаться.
Вместо заключения
Если совсем коротко, то всё сводится к семи шагам:
Изолировать заражённые системы.
Не выключать и не перезагружать их без необходимости.
Ничего не удалять и не чистить.
Не начинать восстановление из бэкапов.
Закрыть очевидно скомпрометированные доступы.
Зафиксировать, что произошло и что уже успели сделать.
Остановиться и дальше действовать уже по плану.
Это не полноценный Incident Response Plan и не универсальная инструкция на все возможные случаи, но с чего то надо начать Эти семь правил — вполне нормальное начало. когда вы не знаете, что делать.
